alt Hacker NewsI get where you come from, but really needs it to be a whole SQLite instance per database? Wouldn’t be more efficient just logic separation in a larger DB?
Better usage of resources and it always allows a parent style agent do complex queries (e.g: intersection of two different actors data doesn’t need to fetch all, copy and do it in buggy non sql code)
Hey! This is a common question.
In our experience, most apps don't need cross-tenant queries outside of BI. For example, think about the apps you use on a daily basis: Linear, Slack, ChatGPT all fit well with an actor-per-workspace or actor-per-thread model.
To be clear, we're not trying to replace Postgres. We're focused on modern workloads like AI, realtime, and SaaS apps where per-tenant & per-agent databases are a natural fit.
Using SQLite for your per-tenant or per-agent databases has a lot of benefits:
- Compute + state: running the SQLite database embedded in the actor has performance benefits
- Security: solutions like RLS are a security nightmare, much easier to have peace of mind with full DB isolation per tenant
- Per-tenant isolation: important for SaaS platforms, better for security & performance
- Noisy neighbors: limits the blast radius of a noisy neighbor or bad query to a single tenant's database
- Enables different schemas for every tenant
- AI-generated backends: modern use cases often require AI-generated apps to have their own custom databases; this model makes that easy
A few other points of reference in the space:
- Cloudflare Durable Objects & Agents are built on this model, and much of Cloudflare's internal architecture is built on DO
- https://neon.com/use-cases/database-per-tenant
- https://turso.tech/multi-tenancy
- https://www.thenile.dev/
- Val.town & Replit
> Better usage of resources
I'd be curious to hear more about what you mean by this.
> always allows a parent style agent do complex queries
Do you have a specific use case in mind where agents need to query other agents' data?