Rivet previews 3.0 actor runtime with claimed 8ms cold starts

• Rivet 3.0 is in preview with claimed 8 ms actor cold starts, 0.7 ms SQLite writes and 78 KB of RAM per actor, according to Rivet's announcement.
• WarpDrive backs actor storage with S3 while serving active data from disks, the mechanism behind Rivet's outage-resilience claim. Reads requiring offloaded data still wait on S3.
• Rivet Cloud charges for hardware rather than awake actor hours or individual reads and writes, according to Rivet's pricing post.

Rivet's most interesting swap is S3 replacing NATS as its message broker. Filesystem offload can replace object storage entirely, while Rivet manages BYOC deployments through an outbound connection from the customer's VPC.

Rivet describes 3.0 as one stateless binary with S3 as its only dependency in the launch post. WarpDrive replaces the Postgres or FoundationDB dependency used in 2.x and gives every actor its own SQLite database.

The storage path has three parts:

1. Commit: Writes land on disks across three availability zones. Acknowledgment follows durability on a majority of them.
2. Offload: Data moves to S3 in background batches, keeping S3 outside the synchronous write path.
3. Read: Hot data comes from memory; cooler resident data comes from WarpDrive disks. Wake-up pages are loaded before actor code runs.

Rivet's published SQLite measurements are:

• Writes: 0.69 ms p50, 0.80 ms p99.
• Reads: 0.20 ms p50, 0.24 ms p99.

The headline 8 ms cold-start claim differs from the launch page's 6.9 ms figure for a new actor. Its FAQ separately reports two existing-actor wake paths:

• Data on SSD: About 5 ms to wake.
• Data offloaded to S3: 689 ms p50 to wake and answer the first SQLite query against a 47 MiB database.

During an S3 outage, writes and reads of recent data remain available through WarpDrive's disks. Reads requiring older, offloaded data wait for S3 to return, according to the same FAQ.

Actors live inside an existing worker process rather than each requiring a container or VM, according to the GitHub README. The launch post says their durable state survives machine failure, allowing actors to move to another machine.

The published memory figures differ: Rivet advertises 78 KB per actor in its announcement, while the launch page quotes 72 KB.

Rivet publishes its Apache 2.0-licensed code in the repository linked at launch. Its deployment options include:

• Embedded: Run the binary inside an existing backend.
• Self-hosted: Run a single Docker container pointed at a bucket. Supported stores include S3, Google Cloud Storage, Azure Blob Storage, Cloudflare R2 and MinIO.
• BYOC: Rivet operates the stack inside the customer's VPC. The BYOC docs identify this offering as Enterprise Edition.
• Rivet Cloud: Hosted on Google Cloud today, with AWS forthcoming.

Self-hosting still incurs hardware and object-storage costs, according to the launch FAQ. Rivet Cloud's announced billing removes the separate actor-hour and read/write meters:

Three Rivet 2.x features are absent from 3.0, according to the launch notes:

• Multi-region.
• Serverless.
• ACLs.

Rivet says all three will arrive before 3.0 leaves preview, alongside further hardening under production load.

The RivetKit SDK and protocol remain unchanged, but the promised zero-downtime migration tool is still forthcoming. Rivet 2.x remains supported during the preview.