4 ms·

I 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? Bet

I 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)

NathanFlurry 7mo ago
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://neon.com/use-cases/database-per-tenant - https://turso.tech/multi-tenancy https://turso.tech/multi-tenancy - https://www.thenile.dev/ 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?

NathanFlurry 7mo ago

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://neon.com/use-cases/database-per-tenant - https://turso.tech/multi-tenancy https://turso.tech/multi-tenancy - https://www.thenile.dev/ 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?