One database.
Six solutions.
RAG, agents, recommendations, fraud detection, personalization, live analytics — six workloads that usually mean five systems and a sync pipeline. Here each one is a different composition of the same substrate: SQL, vector, graph, full-text, /watch and /ask over the same rows, written atomically.
Pick the workload. The substrate is the same.
Each page below is a use case, not a product. You are reading six ways to compose the same atomic write primitive — not evaluating six things to buy.
Row + dense + sparse commit in one atomic write. Retrieval can't surface a vector pointing at a row that no longer matches.
Memory, knowledge and operational state in one transaction. The agent never reads half-updated context.
Vector similarity, graph signal and SQL filters composed in one query plan, against one consistent snapshot.
Reactive /watch over the transaction table, ring detection on the same store. Zero lag between detector and data.
The click and the preference vector land in the same atomic write. The next request sees both.
GROUP BY in milliseconds over fresh rows, with EXPLAIN ANALYZE showing estimated vs actual on every plan.
Every solution rides the same write.
Insert a row with an embedding, a full-text field and a typed relation, and all four updates commit in one append. A concurrent reader — a retrieval call, a rule engine, a dashboard — cannot observe a state where the row exists but the vector index hasn't caught up or the reverse edge is missing. How the substrate works →
That one property is what each solution page keeps cashing in: RAG that can't drift, agents that read their own writes, detectors with zero lag behind the data. A stack of separate stores needs a saga, a reconciler and a skew detector to approximate it.
The trade-off is honest: multi-TB historical scans belong in a warehouse. Fresh, operational data composed across shapes is the sweet spot. Full architecture →
> POST /v1/tenants/:t/rows/products
> { "name": "trail runner", "embedding": […],
> "description": "…", "brand": "b_12" }
committed atomically
row products/p_1 ✓
vector hnsw entry ✓
posting bm25 term postings ✓
edge brand ↔ product (both) ✓
a concurrent reader sees all four — or noneOne primitive, six compositions.
Every chip below is a shipped module, and every combination runs in one plan against one consistent snapshot — no cross-system merge in your application code.
Hybrid retrieval — dense + BM25-style sparse + a SQL filter in one query, with a min_score floor so an empty result is a real result.
Durable memory, typed relationships and live operational state written together — read-your-writes context every session.
Similarity + who-also-bought signal + inventory predicates in one plan. Adaptive over-fetch keeps k survivors after the filter.
Subscribe to the transaction prefix; run PageRank and triangle enumeration on the same store the rule predicates read.
Click row + preference vector in one atomic batch; the next personalised retrieval reads the new state immediately.
Streaming aggregate executor over fresh rows — GROUP BY, aggregate over expression, predicate pushdown to secondary indexes.