Introduction
The Sovereign Engine is a multi-region, zero-garbage-collection, off-heap δ-CRDT database engine. It solves a specific, hard data problem: how to maintain a single, convergent, causally-attributable view of state across a large fleet of mutually-distrusting nodes that partition, heal, reorder, duplicate, and drop messages — while keeping the write/read hot path free of allocator pressure, futex stalls, and cache-line contention, and while being post-quantum-secure from day one.
Documentation basis
Every claim in this portal is grounded in the engine's source — a real package, type, and test backs each one. Where a number is a benchmark floor, a best-case reading, or a different layer entirely, it says so.
Status — research preview, not production-ready
The Sovereign Engine is a research preview, not production-ready software. The core is measured and verified on real hardware, but the engine is shared early so the design and the numbers can be checked — do not trust it with data you cannot afford to lose. Where a capability is labeled Verified on this portal, that means it is wired into the serving path and backed by a test gate or a silicon run — it is not a claim that the engine as a whole is production-ready.
The data problem it addresses
Most operational databases model state as either a mutable row (last-writer-wins, single site of truth) or an append-only operational log (event sourcing with a replay-based read model). Neither handles the multi-region edge case well:
- a mutable row conflicts under concurrent multi-region writers;
- an operational log conflates what happened with what the system believed to be true at a given moment.
The Sovereign Engine instead models state as a tri-temporal CRDT — keyed simultaneously by:
system_time— when the system observed the fact,valid_time— when the fact was true in the real world,assertion_time— the causal/assertion epoch under which the fact was claimed,
with a fourth decision_time carried on the wire. State is an Add-Wins Set lattice element folded by a merge-union Join, so concurrent writers converge without coordination and without losing history.
The durable tier materializes this tri-temporal lattice as an off-heap LSM tree (SkipListArena MemTable → per-entity Arrow IPC L0 files → merged L1 files) with bitemporal point-in-time (AsOf) and interval (Range) queries, a read-your-writes live δ-CRDT HAMT merge, and tri-temporal dominance pruning with an auto-inferred garbage-collection horizon.
Operating envelope
| Metric | Value | Source / caveat |
|---|---|---|
| CRDT core microbench (NOT ingest) | 50,736,038 ops/s gate-passing floor at GOMAXPROCS=32, ARM64 Graviton; this tree re-measures 68,278,197 ops/s | CORE microbench — in-process HAMT.Set crucible: no Ed25519 verify, no envelope, no network, no TLS, no persistence. The floor is the ≥50M gate; the current tree clears it with margin (68,278,197 ops/s on a 2026-09-03 re-run; the honest range is 50.7M–68.3M ops/s). Load-bearing contrast: 1.1M ops/s with false sharing vs this range (1.6% efficiency). Provenance: measured on this tree (c8g.8xlarge, Graviton4 CPU 0xd4f, Go 1.26.1) |
| Production ingest rate | 5.7M–6.0M deltas/sec @32c, N=100–256 batching (single-origin shared; multi-origin ceiling 12.5M–14.7M) | The receive path measured in-process — one Ed25519 verify per frame, envelope decode, CRDT apply; no socket, no disk. ~8–12× below the core number, because the core number omits the ~60µs per-frame Ed25519 verify |
| Hot-path allocations | 0 allocs/op for HAMT.Set | TestHotPathZeroAllocations (pkg/sync/physics_test.go); raceEnabled build-tag pair self-skips under -race |
End-to-end Join benchmark | ~5.5M ops/s, ~8174 ns/op, 472 B/op, 6 allocs/op | BenchmarkCRDTEngine_Join at 2 GiB arena; 64 MiB arena panics HamtArena: OOM at ~1M ops due to reclamation lag |
| Silicon ingest (on-metal) | 5.7M–6.0M deltas/sec @32c (N=100–256 shared; multi-origin ceiling 12.5M–14.7M) | First-hand on c8g.8xlarge (Graviton4, Go 1.26.1), 2026-09-15 — supersedes the 2026-07-30 "1M events/sec" sector bench |
| Ed25519 verify cost | ~60.19 µs/op | The crypto-dominated ingress cost; the cheap-gate stack exists to drop forged frames before this verify |
| ML-DSA-65 (post-quantum) | sig = 3309 B, pub = 1952 B (51.7× sig inflation vs Ed25519 64 B); verify ~73.7 µs | filippo.io/mldsa; compiled into the default build (no build tag), with hybrid Ed25519+ML-DSA-65 signing opt-in at runtime via --hybrid-sign/--hybrid-verify (both default false) |
| 100 node processes on 3 machines, one per region | Convergence target met on the published run — 10K keys converge in 8.95s; six of seven logged runs between 6.6s and 8.7s, one miss at 10.15s; integrity verification armed, production checkpointing. Crash recovery proven — bounded recovery re-equals the checkpoint root | A known convergence tail (~1 run in 7) is the current hardening target — see Verification & Status |
Throughput-honesty disclosure
The 50.7M ops/s figure is the CRDT CORE microbenchmark gate floor — the in-process HAMT.Set data-structure crucible with everything else stripped out — not the production ingest rate (which is 5.7M–6.0M deltas/sec). This tree re-measures the crucible at 68,278,197 ops/s @32c — the honest range is 50.7M–68.3M ops/s (c8g.8xlarge, Graviton4, Go 1.26.1); the gate-passing floor is 50,736,038. Quoting any single peak as "the engine's sustained throughput" is the hero-number round-up the cache-line post-mortem forbids — so the floor, the measured range, and the ingest rate are shown together, and no figure can be misread in isolation.
Every benchmark carries its hardware and its provenance. A hardware-honesty gate (TestGate_GearHonesty) forbids relabeling a 4-core number as a 32-core one; numbers are reported here as numbers, never as adjectives.
Where to go next
- Verification & Status — the measured evidence for convergence, crash recovery, and durability, and the honest boundary of what's not yet proven.
- Core Architecture & Design — the layered packages and the end-to-end request/data flow.
- Design Rationale — the five physical laws and why each is non-optional.
- Key Features & Specialties — the concrete specialties, with where each lives.
- Quickstart — run a node and write/read through the SDK.
- Integration & Usage — the binary, the SDK, the control surface, and an honest readiness assessment.
- Primary Use Cases — where the engine excels.
- GitHub Repository — view the Sovereign Engine source code on GitHub.