Hey HN! We posted Rivet Actors here previously [1] as an open-source alternative to Cloudflare Durable Objects.
Today we've released SQLite storage for actors (Apache 2.0).
Every actor gets its own SQLite database. This means you can have millions of independent databases: one for each agent, tenant, user, or document.
Useful for:
- AI agents: per-agent DB for message history, state, embeddings
- Multi-tenant SaaS: real per-tenant isolation, no RLS hacks
- Collaborative documents: each document gets its own database with built-in multiplayer
- Per-user databases: isolated, scales horizontally, runs at the edge
The idea of splitting data per entity isn't new: Cassandra and DynamoDB use partition keys to scale horizontally, but you're stuck with rigid schemas ("single-table design" [3]), limited queries, and painful migrations. SQLite per entity gives you the same scalability without those tradeoffs [2].
How this compares:
- Cloudflare Durable Objects & Agents: most similar to Rivet Actors with colocated SQLite and compute, but closed-source and vendor-locked
- Turso Cloud: Great platform, but closed-source + diff use case. Clients query over the network, so reads are slow or stale. Rivet's single-writer actor model keeps reads local and fresh.
- D1, Turso (the DB), Litestream, rqlite, LiteFS: great tools for running a single SQLite database with replication. Rivet is for running lots of isolated databases.
Under the hood, SQLite runs in-process with each actor. A custom VFS persists writes to HA storage (FoundationDB or Postgres).
Rivet Actors also provide realtime (WebSockets), React integration (useActor), horizontal scalability, and actors that sleep when idle.
GitHub: https://github.com/rivet-dev/rivet
Docs: https://www.rivet.dev/docs/actors/sqlite/
[1] https://news.ycombinator.com/item?id=42472519
[2] https://rivet.dev/blog/2025-02-16-sqlite-on-the-server-is-mi...
It’s crazy how pretty much every tool people post to support AI systems is already in Erlang/OTP or in elixir standard libraries.
We recently replaced an isolated feature built on Durable Objects with Rivet Actors, to allow for much better interop with the rest of our infra (which is built on AWS/Vercel), and are happy with it so far.
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!
I love the idea of DOs and I'm happy to see an OSS implementation.
Would it be interesting to write about comparisons against Cloudflare Durable Object to the project README? Both for clarity and marketing reasons.
“sqlite per actor” feels like very clean actor level isolation. the part I am more curious about is how you recommend handling cross actor queries.
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)
[dead]
Really interesting to see these new compute paradigms. I haven't built anything on Durable Objects yet but I can see the appeal and I'd prefer an OSS option.
SqliteDB per tenant may make sense, not sure about per actor. You really don't want to re-implement database transactions.