AI & vector search
Store embeddings as a first-class column, run ANN search in SQL, and keep retrieval context fresh from live streams — no separate vector database.
The problem
Why this is hard today
RAG and semantic-search stacks bolt a dedicated vector database onto the side of the system of record. Embeddings live in one store, the source rows in another, and a batch job shuttles between them — so retrieval is always answering from a stale snapshot of the corpus.
The freshness gap is the whole problem for retrieval-augmented generation: an assistant that retrieves last night’s context cannot answer about what happened this morning. And when the online features that drive a model live in yet another store, read-your-writes is lost exactly where inference needs it.
What AI platforms need is embeddings stored next to the data, approximate-nearest-neighbor search expressed in the same SQL as everything else, and a way to keep the vector index fresh from the event stream instead of a nightly re-embed.
Architecture
How NYXDB does it
Embeddings are a vector(N) column; a per-part HNSW index is built at flush; an ANN query rewrites to the VectorTopK operator. Continuous transforms keep embedding-enriched tables fresh from the stream.
- 01
Store
Embeddings live in a vector(N) column alongside the source columns — one table, one row.
- 02
Index
A per-part HNSW index (vendored usearch) is built at flush; bare INDEX hnsw defaults to the cosine metric.
- 03
Search
ORDER BY cosine_distance(emb, $q) LIMIT k rewrites to the VectorTopK ANN operator (AnnRewriteRule).
- 04
Stay fresh
A CREATE TRANSFORM materializes embedding-enriched rows from the event stream — fresh retrieval context, no batch re-embed.
Real SQL
In practice
CREATE TABLE emb_t ( id UInt64, ATTRIBUTE (emb vector(8) INDEX hnsw));SELECT id, cosine_distance(emb, '[1,0,0,0,0,0,0,0]')FROM emb_tORDER BY cosine_distance(emb, '[1,0,0,0,0,0,0,0]')LIMIT 3;-- materialize embedding-enriched rows from the event streamCREATE TRANSFORM enrich_docs INTO doc_embeddings ASSELECT doc_id, embFROM incoming_docs;Every statement follows the engine’s own test SQL shapes. See the SQL reference for full syntax.
Capabilities
What you get
First-class embeddings
vector(N) columns store embeddings next to source data — no separate store.
HNSW ANN
Per-part HNSW index (usearch) built at flush; ORDER BY distance → VectorTopK.
Cosine + more
cosine, L2, and inner-product distance functions; bare INDEX hnsw defaults to cosine.
Streaming RAG
CREATE TRANSFORM keeps embedding-enriched tables fresh from the stream.
Online features
Keyed tables serve online features with read-your-writes and exact counts.
One engine
Vectors, source rows, and features share one runtime and one SQL surface.
Proof
Measured where it counts
vector(N) raw-ABI kernel speedup
PR #370 / #131 (kernel, not end-to-end)
ANN rewrite over the HNSW index
AnnRewriteRule (ADR-064)
query latency class
placeholder — not yet substantiated
▲Figures marked TODO-verify are placeholders pending a published, reproducible benchmark; substantiated numbers cite their source.
Learn more
Related documentation
Retrieval that is always fresh
Store embeddings, run ANN search, and keep context live — all in SQL.