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 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 restores full state in seconds, not hours.
- ·2026-04-30 drill passed
- ·continuous 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
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.
- RAG. Sparse + dense + the original row, all in one atomic upsert. The retrieval can't return a vector pointing at a row that no longer matches.
- Agent memory. JSON-shaped values + embeddings + lineage, transactional. The agent's view never lies about what was just written.
- Streaming personalization.
/watchsees every write the instant it lands - including the new vector.