One database, every query shape
OriginChain is one managed database that answers five query shapes against the same rows: SQL, vector similarity, full-text, graph traversal, and natural language. The same write is visible to every shape atomically, so there is no sync job standing between a database and a vector index.
The alternative is what most AI applications end up running. You start with a relational database for your rows. Then you need similarity search, so you bolt on a vector database. Then keyword search, so a full-text index. Then a recommendation feature wants graph traversal, so that’s a fourth system — and most of your engineering time goes into pipelines that copy data between four stores and pray they stay in sync.
The five shapes:
- SQL — typed
SELECTs, joins, aggregates, window functions. - Vector search — top-k similarity with cosine, dot, and L2.
- Full-text — BM25 ranking with stemming across 18 languages.
- Graph — BFS, shortest-path (Dijkstra), reverse traversal, PageRank.
- Natural language — ask a question in plain English; the engine plans and runs it.
One bearer token, one URL, one bill. No second store to sync.
The part that actually matters: atomicity
The reason teams tolerate the multi-system stack is that nobody has made the single-system version consistent. The whole point of OriginChain is that the same write is visible to every query shape, atomically. Insert a product row and its embedding in one request, and a vector search sees it the instant a SQL query does. There’s no replication lag between your “database” and your “vector index,” because there is no second copy — the vector lives next to the row it describes.
That’s the difference between “we support vectors” and “vectors are a first-class shape of the same store.”
A concrete example
Say you’re building product search. A user types “lightweight running shoes under $120.” On a typical stack that’s three systems and a coordinator. On OriginChain it’s one store:
- BM25 full-text over the product descriptions for the keywords,
- a vector top-k for semantic similarity to the query embedding,
- a SQL predicate for
price < 12000,
all against the same rows, returning JSON. When you add a product, every one of those shapes sees it immediately — no nightly reindex, no sync job to monitor.
On performance, with receipts
We don’t think you should take “it’s fast” on faith, so the runs we have published are on /benchmarks. Vector search runs HNSW for low-latency recall and IVF-PQ for large corpora, where compressing each vector keeps the index on a single box. We have not published a measured result at 100M scale. For smaller corpora where latency is everything, the HNSW path runs at single-digit-to-low-double-digit-millisecond p99. In-region typed queries return under ~100 ms p99.
Natural language that compiles to a plan, not a prompt
The /ask endpoint is not a chatbot wrapper around your data. A plain-English
question compiles to a real query plan — the same plan tree SQL and vector queries
use — which you can inspect before it runs. Ask the same shape twice and the plan
is cached, so the repeat skips compilation and returns warm in tens of milliseconds.
It’s natural language as a front-end to the planner, not a prompt tax bolted on
top.
What’s honest to say we don’t do yet
We’d rather name the gaps than have you find them:
- Managed embeddings are still bring-your-own-vectors today. You compute embeddings on your side and write the vectors; we store, index, and search them. Server-side text→vector is on the roadmap.
- SQL is a growing subset. Joins, aggregates, window functions, and
subqueries work; recursive CTEs and
UNIONdon’t yet. Every unsupported shape fails with a clear message that tells you the workaround, not a silent wrong answer.
Try it
OriginChain is a managed, single-tenant, region-isolated database. Provision a tenant and run all five query shapes against it from the quickstart, or read how the engine answers each shape in the architecture guide.
OriginChain is built by Silicoyn Technologies. Learn more at originchain.ai.