Benchmarking
How we benchmark Rivet: the cluster setup, what each number measures, and how to reproduce it.
These measurements come from our published benchmark, Rivet Actors against Cloudflare Durable Objects, run on November 5, 2026 with Rivet 3.0.3. The repository has the raw samples, the full report, and the scripts to reproduce every number. Results depend on the workload and hardware.
Setup
| Region | Azure eastus2, three availability zones |
| Control plane | 3 instances, one per zone, each Standard_L8as_v5: 8 vCPU, 64 GiB RAM, about 1.7 TB local NVMe (ext4, noatime) |
| Durability | Every write is acknowledged by 2 of 3 instances, and at least one of those is in another zone |
| Node and client | 1 node VM, Standard_D16as_v7: 16 vCPU, in the first zone. The load generator runs on the same VM. |
| Software | Rivet 3.0.3 (rivetdev/engine:3.0.3 and rivetkit@3.0.3), Node.js 24 |
| Object storage | Azure Blob Storage in the same region, with locally redundant storage (LRS) |
Results
Milliseconds, p50 / p99, nearest rank, no trimming. Every condition completed without errors.
| Measurement | Samples | p50 | p99 | What it measures |
|---|---|---|---|---|
| Cold start | 1,500 | 4.30 | 4.99 | Client send to full reply from a new Rivet Actor, through the gateway. Includes scheduling, storage creation, and framework startup. |
| Wake | 1,200 | 6.26 | 8.15 | Client send to full reply from a Rivet Actor asleep for at least 10 seconds. |
| Warm request | 2,000 | 0.45 | 0.79 | Round trip of a request to a running Rivet Actor. |
| Durable write (3 AZ) | 1,200 | 0.69 | 1.07 | One SQLite row inserted, timed around the query in the Rivet Actor, including the write to a majority of disks across zones. |
| Warm point read | 1,200 | 0.09 | 0.54 | A point read from SQLite’s memory cache, timed around the query in the Rivet Actor. |
| Point read after sleep, 50 MB database | 1,200 | 0.90 | 1.36 | The first random point read after at least 13 seconds asleep, timed around the query in the Rivet Actor. |
Throughput, the Durable Objects results, and the remaining conditions are in the repository.
Comparison baseline
The Rivet landing page compares Rivet Actors with sandboxes, using E2B as the baseline. We did not measure the E2B figures on the setup above. They come from E2B’s documentation and a third-party benchmark.
| Rivet Actor | E2B sandbox | Difference | |
|---|---|---|---|
| Cold start, p50 | 4.30 ms | 1.27 s | About 295× |
| Cold start, p99 | 4.99 ms | 1.70 s | About 341× |
| Memory | 72.4 KB per running Rivet Actor | 512 MiB per sandbox | About 7,242× |
Memory
- Why E2B: E2B has one of the smallest default memory allocations among sandbox providers, which keeps the comparison conservative.
- E2B figure: 512 MiB per sandbox, the default documented in E2B’s billing documentation as of November 4, 2026. This is allocated memory, not measured memory consumption or a minimum.
- Node.js floor: Each sandbox requires its own Node.js process, so a sandbox running Node.js cannot use less memory than one Node.js runtime, however small its allocation.
- Rivet figure: 72.4 KB is the resident memory (RSS) added by one running Rivet Actor, measured in September 2026 with the Rust rivetkit SDK. Rivet Actors share their node’s process instead of each starting their own.
Cold starts
- Why E2B: E2B is a standard baseline, and using it for memory and cold starts keeps the comparison consistent.
- Startup time: 1.27 seconds median and 1.70 seconds p99, from ComputeSDK’s October 30, 2026 sandbox benchmark.
- Methodology: 100 sandboxes launched concurrently, with 100% success. Timing starts at
compute.sandbox.create()and ends after the first successfulrunCommand()inside the sandbox.
Rivet’s cold start measures Rivet Actor creation through the first response, with one request at a time. Comparing the medians gives approximately 295×, and comparing the p99s gives approximately 341×, but these are separate benchmarks with different concurrency and environments.
Storage cost
SQLite on S3 costs about 10.4× less to store long term than replicated SSD storage. This is a calculation from AWS list prices in us-east-1, not a measured Rivet bill.
| S3 Standard | Three Amazon EBS gp3 copies | |
|---|---|---|
| Per GB-month | $0.023 | $0.24 ($0.08 per copy) |
| 1 TB for a year | $276 | $2,880 |
- Why gp3: AWS recommends General Purpose SSD volumes for most workloads and describes gp3 as its lowest-cost SSD volume type.
- Why three copies: S3 Standard stores data across at least three Availability Zones at no extra charge. An EBS volume is tied to one zone, so matching that placement takes one volume per zone.
- Prices: S3 Standard uses the first 50 TB tier. gp3 uses storage only, with its included 3,000 IOPS and 125 MB/s.
- Reads and writes: This comparison does not include the cost of reads and writes. We assume that cost is amortized because Rivet batches reads and writes to S3, so its share of the total cost is a small fraction. This is an assumption, not a measurement.
- What else this excludes: Cross-zone replication transfer and extra provisioned gp3 performance. It also excludes the replicated local disks that hold recent writes before they move to object storage, so the figure applies to data at rest in S3.
Reproducing it
Follow the Reproduce it steps in the repository. Its scripts provision the Azure VMs, deploy the control plane and node, run each condition, and regenerate the report from the raw samples.