Start free
01 · the substrate

One database.
Every shape. One write.

Rows, vector embeddings, full-text postings and graph edges all live on one hash-keyed key/value substrate. A write that touches several shapes lands in a single write-ahead log append — all shapes commit or none do, by construction rather than best-effort.

Start free Architecture
one write SQL GRAPH /ASK VECTOR SEARCH every shape updated together
one write, every shape

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.

your write 1 saved durable log 2 ROWS VECTORS SEARCH GRAPH 3 all update together — or none do
by design
01 Atomic cross-shape writes

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
02 Hash-keyed k/v

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
03 Snapshot-bootstrap HA

A standby is brought up on full state, not rebuilt from scratch.

  • ·2026-04-30 drill passed
  • ·asynchronous streaming replication
  • ·automatic failover (no split-brain)
04 Dedicated compute when you need it

On dedicated configurations, compute and database storage are not shared with any other customer. Free and Starter run on shared, scale-to-zero infrastructure.

  • ·region-isolated
  • ·single-tenant on dedicated configurations
  • ·shared, scale-to-zero on Free and Starter
every shape, one store

Five query shapes. Zero copies.

SQL correlated EXISTS · aggregates · CASE Vector 4 metrics × 4 index variants Graph 9 algorithms · per-hop EXPLAIN Full-text BM25 · phrase · 18-language stemming /ask natural-language query routing
design choice

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.

before 4 systems rows db vector db search graph out of sync consolidate after 1 system one database always in sync
why this matters for AI
RAG

Sparse + dense + the original row, all in one atomic upsert. 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.

by the numbers
5
query shapes shipped
9
graph algorithms
4 × 4
vector metrics × index variants
1
atomic write across every shape
0
cross-store sync jobs
go deeper

The full architecture, with every shape drawn out.

Architecture → SQL surface Try it