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 in one WAL frame - by construction, not by best-effort.
One WAL frame, every shape. Either every shape sees the row, or none of them do.
- ·single-writer contract
- ·byte-level WAL invariant
- ·cutover atomic at the substrate level
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
- ·frame-stream replication
- ·leader-election via durable lease
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.
A separate store per shape would have meant cross-store coordination on every write. We don't do it.
Single-writer is the contract. Read-your-writes is immediate. No replication-lag explainers in your runbook.
Managed and single-tenant only. Operating the substrate at the SLA we promise is our job, not yours, and your bytes never touch another tenant's process.