Benchmark comparison
The two rules this page lives by
- Never compare across layers. An in-process data-structure number and a networked-server number are not the same thing, and putting them on one axis is the oldest marketing trick there is.
- Never compare a write to a read. Reads are cheaper than writes on every engine — ours included — so we compare write-to-write, the direction our ingest path actually runs.
Sovereign Engine is a research preview, not production-ready. Everything below is reproducible; where we fall short, we say so before you have to find it.
In-memory writes — the only chart where a bar-to-bar comparison is fair
Every bar here is an in-memory write, so the lengths actually mean something against each other. Ours is the only one paying for a signature check and a CRDT merge on the write path — one Ed25519 verify per frame, amortized across the 100–256 deltas it carries. Reads are cheaper on every engine — Dragonfly's reads reach 4M–15.5M and we don't match them; on writes, we lead.
That's our bare data-structure core — no network, no crypto, no disk. No other engine publishes a comparable isolated core number (they're all networked servers, and the network is the point), so we don't chart it against them. It isn't a request rate; it's the headroom — the reason a signature check and a CRDT merge can sit on the write path and it still serves millions. receipts ↗
The durable engines production trusts — and why we're not on this chart
These engines pay for durability and replication on every write, and that costs one to two orders of magnitude. We are a research preview and we have not shipped that cost yet — so we don't put a Sovereign bar here and pretend the comparison is fair. This is the field we intend to join; when the durable path is our measured path, we'll publish that number the same way.
Where's DynamoDB? It's a managed, sharded AWS fleet — its published Prime-Day peaks are tens of millions of requests/s in aggregate across the entire service, not per node — so it has no honest place on a per-node axis. source ↗
Every number, with its workload, hardware, and what's actually measured
| System | Workload | Hardware | Throughput | Latency | What's actually measured |
|---|---|---|---|---|---|
| Sovereign | CRDT core (HAMT.Set) | Graviton4 · 32 cores | 50.7M–68.3M ops/s | — | In-process data structure: no network, crypto, or disk ↗ |
| Sovereign | Production ingest | Graviton4 · 32 cores | 5.7M–6.0M deltas/s | — | One Ed25519 verify per frame (100–256 deltas) + envelope decode + CRDT apply per delta ↗ |
| Sovereign | Convergence · 100 node processes | 3× c7gd.8xlarge · one per AWS region | 8.95 s to converge (published run) | — | Leaderless convergence time — a capability, not ops/s; six of seven logged runs 6.6–8.7 s, one miss at 10.15 s ↗ |
| Dragonfly | write / read | 48 cores · in-memory | 4.2–5.2M write · 4–15.5M read | — | In-memory server, no crypto ↗ |
| Redis | SET | single core · in-memory | ~72K (1.8M pipelined) | sub-ms | In-memory server, no crypto ↗ |
| FoundationDB | 90/10 read/write, cluster | 24× c3.8xlarge · 384 procs | 8.2M ops/s | commit 1.5–2.5 ms | Cluster peak, transactional ↗ |
| FoundationDB | 90/10, single core | E3-1240 · memory engine | 90K reads / 35K writes /s | — | Single-core transactional ↗ |
| TigerBeetle | transfers (batched) | single core · replicated | ~100K–450K transfers/s | — | Double-entry, consensus + durable ↗ |
| ScyllaDB | write | per node · RF=3 | ~75K ops/s | — | C++ durable, quorum ↗ |
| Cassandra | write | per node | ~42K–71K ops/s | — | Multi-master, last-write-wins ↗ |
| CockroachDB | TPC-C | multi-node · 3× replicated | 128,000+ tpmC | p90 tens of ms | TPC-C new-order transactions / minute ↗ |
| etcd | write | 3-node Raft | ~44K–50K writes/s | — | Consensus store ↗ |
| MongoDB | document ops | single node · replica set | tens of K ops/s | — | Document database, durable ↗ |
| MySQL | OLTP (sysbench) | single node | ~10K–30K TPS | — | Relational, durable ↗ |
| PostgreSQL | pgbench (durable) | single node | ~5K–12K TPS | — | Relational, durable writes ↗ |
| DynamoDB | read/write (managed) | AWS fleet · aggregate | millions req/s aggregate | single-digit ms | Managed, sharded service — not a per-node number ↗ |
Read across a row, not down a column: a 68.3M in-process core and a 128,000-tpmC durable cluster are not the same measurement — the workload and measured columns exist so you never confuse them.
Time and convergence — the comparison that's a model, not a number
Raw speed is table stakes. Our thesis is about time and convergence. Nobody here tracks three axes of time, and nobody else publishes a measured convergence time for a leaderless multi-region fleet.
| Engine | Time model | Convergence | The honest note |
|---|---|---|---|
| Sovereign | Tri-temporal — system × valid × assertion | Leaderless — 100 node processes on 3 machines, 8.95 s on the published run | Three time axes, and a convergence time that is measured on real silicon rather than asserted. |
| XTDB | Bi-temporal — valid + system (2 axes) | Single-writer / log | The bitemporal leader; we add the third axis (assertion time). |
| Datomic | Transaction-time only (1 axis) | Single transactor | The immutable pioneer; a single point of write. |
| CouchDB | None (MVCC revisions) | Multi-master, eventual + manual conflicts | The original multi-master sync — unbounded, conflicts are yours. |
| Realm / Atlas Device Sync | None | Client → cloud sync | Offline-first mobile sync to a central cloud, not cluster convergence. |
XTDB's bitemporality is the strongest prior art and it's genuinely good — we add the third axis (assertion time: what did we believe, and when did we learn we were wrong?). CouchDB pioneered multi-master sync; we keep it leaderless, merge conflicts by arithmetic instead of handing them to you, and publish how long convergence took. We're standing on their ideas, then going further.
Every figure carries its layer, its conditions, and a source. We compare writes to writes, we never put a read on a write's axis, and we don't chart ourselves against engines paying a cost we haven't shipped. If a number here doesn't reproduce, or a comparison smuggles a layer or a read-for-a-write — that's a bug. Please open an issue.
How to check us
- Every figure has a source — hover the bars, or read the receipts in
docs/evidence/. - Run it yourself.
scripts/benchmark.shreproduces the core gate;go test ./...runs clean. On a small box the 32-core gate self-skips rather than print a misleading number. - The harness is published. The convergence gate, the workload generator, and the integrity checks are all in the repo. We would rather you re-run it than trust it.
What we deliberately don't do
- No bare "N million ops/s" headline without conditions.
- No read number passed off as a write number, or vice versa.
- No in-process microbench presented as a server rate.
- No cluster aggregate presented as a per-node figure.
- No "N× faster than Y" ratio without the absolute, the core counts, and the method.
- No durability or consensus claimed that the measured path didn't pay for.
Find a number here that doesn't reproduce, or a comparison that smuggles a layer or a read-for-a-write — that is a bug. Please open an issue.