One database.
Every shape. One write.
We replaced Postgres + a vector DB + a graph DB + a search engine + a watcher with one substrate. Every write across every shape commits atomically — all shapes or none, by construction, not by best-effort.
One WAL append. Every shape commits together.
Rows, vector embeddings, full-text postings and graph edges land on the same write-ahead log in a single append. There's no second store to reconcile and no window where one shape is ahead of another.
One atomic write, every shape. Either every shape sees the row, or none of them do.
- ·single-primary guarantee (no split-brain)
- ·all-or-nothing writes
- ·atomic cutover across every shape
No relational engine, no second physical store. Shapes are key shapes on one substrate.
- ·O(1) point lookups
- ·key-prefix scans
- ·secondary indexes are first-class
Failover brings a standby up on full state in about a minute, not hours.
- ·2026-04-30 drill passed
- ·asynchronous streaming replication
- ·automatic failover (no split-brain)
Your data plane is yours alone. No shared engine, no noisy neighbour.
- ·region-isolated
- ·single-tenant
- ·no shared multi-tenant engine
Six query shapes. Zero copies.
Why a single substrate, not a multi-engine stack.
We picked a single hash-keyed k/v substrate so cross-shape atomicity is free. Adding a separate columnar store would have given us better analytical scans at the cost of atomicity — and we judged atomicity the moat.
The trade-off shows up in workloads. Multi-TB historical scans aren't our sweet spot; warehouses do those better. Atomic cross-shape writes on fresh, operational data are.
Sparse + dense + the original row, all in one atomic upsert. Retrieval can't return a vector pointing at a row that no longer matches.
JSON-shaped values + embeddings + lineage, transactional. The agent's view never lies about what was just written.
/watch sees every write the instant it lands — including the new vector.