SqliteDB per tenant may make sense, not sure about per actor. You really don't want to re-implement database transactions.
There have been some small issues but nothing show-stopping, and the Rivet team has been very responsive to help get things sorted (or help us understand when it was us doing something wrong).
Not using the SQLite datastore yet, but I am excited about the possibilities!
However, we are planning on building a query engine that can operate over multiple databases. One option we're considering is exposing Rivet SQLite as a DuckDB datasource: https://duckdb.org/docs/stable/data/data_sources
Would it be interesting to write about comparisons against Cloudflare Durable Object to the project README? Both for clarity and marketing reasons.
We're taking a different approach of building the best actor primitive for mainstream languages and letting people build a thin AI layer on top. We did not set out out build for AI when we started it, it was a happy accident.
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)
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
- 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?