Introducing Rivet 3.0 Preview
Rivet 3.0 is built on WarpDrive, a new storage engine with bottomless storage on S3 and the speed of an SSD. S3 is the only dependency, and Rivet is one stateless binary.
Today we’re releasing a preview of Rivet 3.0, built on a new storage engine called WarpDrive.
WarpDrive gives every Rivet Actor bottomless storage on S3 with the speed of an SSD. It also leaves S3 as Rivet’s only dependency, so Rivet now runs as one stateless binary.
We built Rivet 3.0 for agents. Every agent needs its own isolated state, far more data than a typical request, and a fast start the moment a user shows up. Teams also want to run many more of them on the hardware they already own.
WarpDrive: bottomless storage with the speed of an SSD
Every Rivet Actor gets its own SQLite database on WarpDrive. When your Actor writes, the write lands on disk in three availability zones and is acknowledged as soon as a majority of them have it. Later, in the background, the data is offloaded to S3, so storage never runs out.
S3 never sits on the write path. Reads come from memory when the data is hot and from WarpDrive’s disks when it isn’t. When an Actor wakes, the pages it needs are already loaded before your code runs.
Rivet Actors are agent-sized and durable
An Actor is a small unit of memory, storage, and compute.
Its state lives in WarpDrive instead of on the machine, so any machine can run any Actor. Every Actor is isolated, with its own state and its own SQLite database.
Actors are tiny. An Actor is 72 KB. A Kubernetes pod is 200 MB. That means thousands more workloads on every server you already own.
Rivet Actors
0 × 72.4 KB
Kubernetes pods
0 × 200 MB
Actors start fast. A new Actor cold starts in 6.9 ms. A pod takes seconds.
Rivet Actor
6.9 ms
Kubernetes pod
~6 s
Actors are durable and sleep when idle. An idle Actor hibernates and wakes on the next request with its state exactly where it left it. State also survives restarts and machine failures. When a machine dies, its Actors move to other machines with their state intact.
One stateless binary
Rivet 2.x needed a database such as Postgres or FoundationDB, plus NATS for messaging.
In 3.0, WarpDrive replaces the database and S3 replaces the message broker. What’s left is one stateless binary.
Embed it in the backend you already have, self-host it in your own cloud, on-prem, or air-gapped, or use it to sandbox agents at scale.
Open source and self-hostable
Rivet is open source under the Apache 2.0 license. Rivet Cloud runs the same binary you can run yourself, so you’re never locked in.
Running Rivet in your own cloud keeps every Actor’s data in your own account and your own bucket. It runs next to the rest of your infrastructure, on hardware and cloud credits you already pay for, and inside the compliance and data residency boundaries you already have.
Self-host, BYOC, or cloud
Every option runs the same binary. The only difference is who operates it.
Self-host. Rivet runs as a single container on vanilla Docker. Point it at a bucket and it’s ready.
Rivet works with the object store on every major cloud, including Amazon S3, Google Cloud Storage, Azure Blob Storage, and Cloudflare R2. For a fully self-hosted setup with no cloud at all, run it against MinIO.
Bring your own cloud. The whole stack runs inside your VPC, and Rivet manages it for you over an outbound connection. See the BYOC docs.
Rivet Cloud. Create a project on the dashboard and deploy. There’s nothing to operate.
Upgrading from Rivet 2.x
3.0 requires no code changes. It uses the exact same RivetKit SDK and the same protocol as 2.x. The upgrade is entirely in the storage engine underneath.
We’ll launch a migration tool soon that moves existing 2.x deployments to 3.0 with zero downtime and without updating any code.
A few 2.x features haven’t made it to 3.0 yet. Those are multi-region, serverless, and ACLs. If you depend on any of these, stay on Rivet 2.x for now. We’ll bring each one to 3.0 before it leaves preview.
FAQ
Do I need to change my code?
No. Rivet 3.0 uses the exact same RivetKit SDK and protocol as 2.x.
Is Rivet 2.x still supported?
Yes. Rivet 2.x stays supported while 3.0 is in preview, and the migration tool will move you to 3.0 with zero downtime when you’re ready.
What does “preview” mean?
Rivet 3.0 is in preview because multi-region, serverless, and ACLs haven’t landed in 3.0 yet. We’ll also keep hardening it under production load before it leaves preview.
Do reads and writes wait on S3?
No. A write is acknowledged once it’s durable on disk in a majority of three availability zones, and data is offloaded to S3 later in the background. Reads are served from memory or from WarpDrive’s disks. S3 is where your data lives long term, not where requests wait.
How does this compare to other databases on S3?
Most databases built on S3 write directly to S3. Every write waits on S3 and turns into S3 requests, which can cost tens of thousands of dollars even for small workloads.
WarpDrive focuses on SSD speed and affordability. Writes land on disk in three availability zones first, and WarpDrive batches them into far fewer S3 operations in the background.
What happens if S3 becomes unavailable?
Writes and reads of recent data stay fully available, because WarpDrive serves them from its own disks. Only reads of older Actors whose data has been offloaded to S3 wait for S3 to come back online.
How fast does an Actor wake when its data isn’t on SSD?
When an Actor’s data has been offloaded and isn’t loaded on WarpDrive’s SSDs, the Actor reads it directly from S3 as it wakes. Waking the Actor and answering its first SQLite query takes 689 ms at p50 for a 47 MiB database. An Actor whose data is still on SSD wakes in about 5 ms. We’re making cold wakes from S3 even faster soon.
Which clouds does Rivet Cloud run on?
Rivet Cloud runs on Google Cloud today, and AWS is coming soon.
Do I still need Postgres, FoundationDB, or NATS?
No. S3 is the only dependency.
Which object stores work?
The object store on every major cloud, including Amazon S3, Google Cloud Storage, Azure Blob Storage, and Cloudflare R2. For a fully self-hosted setup, use MinIO.
Can I use filesystem storage instead of S3?
Yes. Rivet can offload data to a filesystem instead of an object store.
Are Rivet nodes stateful?
No. Rivet nodes can be ephemeral. Giving them persistent volumes improves cache hit rates, but it isn’t required.
What hardware does Rivet need?
There’s no minimum hardware requirement, and Rivet can run on a single node. For high availability, we recommend at least three nodes spread across three availability zones.
Can I run Rivet on Kubernetes?
Yes. Rivet runs anywhere a container runs, including Kubernetes, Amazon ECS, and plain VMs.
How much does it cost to run?
Your hardware and S3. WarpDrive makes far fewer S3 operations than most databases built on S3, so you’re mostly paying for storage.
Is Rivet open source?
Yes. Rivet is open source under the Apache 2.0 license.
How does Rivet compare to Cloudflare Durable Objects?
Rivet is the open-source alternative to Durable Objects. It’s faster, has no runtime limits, and gives every Actor bottomless storage instead of a 10 GB cap. You can also self-host it, so it runs on-prem.
