Show HN: SQLite for Rivet Actors – one database per agent, tenant, or document (opens in new tab)

(github.com)

45 pointsNathanFlurry26d ago16 comments

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...

[3] https://www.alexdebrie.com/posts/dynamodb-single-table/

16 comments

fastball26d ago

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!

NathanFlurryOP26d ago

Cheers!

siliconc0w26d ago

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.

NathanFlurryOP26d ago

Cheers!

swaminarayan26d ago

“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.

NathanFlurryOP26d ago

We built everything with this architecture internally already at Rivet. It's less common than you might expect to have to query cross-DB in practice.

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

o17525d ago

The lazy migration design is clever for the common case, but I keep getting stuck on what happens when a migration isn't just "add a column." If you need to backfill a derived field or rebuild an index across a restructured table, some unlucky user's request becomes the one that absorbs thirty seconds of migration work instead of the usual milliseconds. And you can't really pre-migrate millions of idle databases either, since the whole point is they only wake on demand. Is there a pattern people are using here, like versioned read paths that serve old-schema data while migrating in the background, or is the practical answer just "don't write heavy migrations"?

fastball25d ago

You can pre-migrate if you want, just by hitting every actor with a request as soon as you deploy the change with a migration.

Personally I think the benefits of lazy outweigh the downside of that single 30s request, but to each their own.

ZeroAurora26d ago

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.

NathanFlurryOP26d ago

Thanks! Any questions in particular on the comparison?

ZeroAurora25d ago

Theory, performance, self-host option, estimated cost, etc. And I see you can deploy rivet on Cloudflare DOs. What situation does it help when we can just use wrangler?

By the way, Cloudflare DO is actually self-hostable with workerd to my knowledge, but it's not an out-of-box experience.

malkosta26d ago

It’s crazy how pretty much every tool people post to support AI systems is already in Erlang/OTP or in elixir standard libraries.

NathanFlurryOP26d ago

Yep, everyone seems to reinventing the actor model from first principles right now.

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.

malkosta25d ago

How do you intend to conquer the preemptive scheduler? System-wide fairness and preventing starvation are essencial steps for this to work well.

nudpiedo26d ago

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)

NathanFlurryOP26d 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://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?

j / k navigate · click thread line to collapse

Show HN: SQLite for Rivet Actors – one database per agent, tenant, or document (opens in new tab)

(github.com)

45 pointsNathanFlurry26d ago16 comments

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

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...

[3] https://www.alexdebrie.com/posts/dynamodb-single-table/

16 comments

fastball26d ago

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!

NathanFlurryOP26d ago

Cheers!

siliconc0w26d ago

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.

NathanFlurryOP26d ago

Cheers!

swaminarayan26d ago

“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.

NathanFlurryOP26d ago

We built everything with this architecture internally already at Rivet. It's less common than you might expect to have to query cross-DB in practice.

o17525d ago

fastball25d ago

You can pre-migrate if you want, just by hitting every actor with a request as soon as you deploy the change with a migration.

Personally I think the benefits of lazy outweigh the downside of that single 30s request, but to each their own.

ZeroAurora26d ago

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.

NathanFlurryOP26d ago

Thanks! Any questions in particular on the comparison?

ZeroAurora25d ago

Theory, performance, self-host option, estimated cost, etc. And I see you can deploy rivet on Cloudflare DOs. What situation does it help when we can just use wrangler?

By the way, Cloudflare DO is actually self-hostable with workerd to my knowledge, but it's not an out-of-box experience.

malkosta26d ago

It’s crazy how pretty much every tool people post to support AI systems is already in Erlang/OTP or in elixir standard libraries.

NathanFlurryOP26d ago

Yep, everyone seems to reinventing the actor model from first principles right now.

malkosta25d ago

How do you intend to conquer the preemptive scheduler? System-wide fairness and preventing starvation are essencial steps for this to work well.

nudpiedo26d ago

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?

NathanFlurryOP26d ago

Hey! This is a common question.

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?

j / k navigate · click thread line to collapse