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.
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
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
Been using it for a bit now, it's very convenient if I may say so myself. We're shipping a big stability update in a few minutes – would love feedback!
Yes. We want to support ACP. They have a spec for HTTP transport in the works, but there is nothing public on it. Trying to backchannel to the right folks.
It’s the only bit of the Cloudflare stack (afaik) that did not have an open-source alternative for the JS ecosystem. I built heavily with DO on another OSS project, but realized it was incredibly problematic that our customers couldn’t truly self-host.
A 1 CPU + 2 GB of RAM + 50 GB ephemeral storage on Cloudflare Containers is $74.90.
The same on Fly Machines is $31.00 (performance-1x, varies by region). Fly Machines has the same sleeping functionality as Cloudflare.
Rivet Containers also has a similar price point of $29.40, but takes a different approach to sleeping (opts for optimizing coldstarts + autoscaling over snapshotting). (I work at Rivet)
They stated on the livestream they're considering TCP, but I suspect UDP is not coming soon since Workers themselves don't support UDP. All traffic going to Cloudflare Containers must be "proxied" through the Workers platform.
Allows you to compile most C or Rust programs to run in it without modification. Also can run Claude Code, Codex, Pi, and OpenCode unmodified.
Working on polishing, security, and documentation so I can share an in-depth deep dive on HN.
https://github.com/rivet-dev/agent-os