AI & SEARCH
AI, RAG & semantic search
Embeddings, keywords, and the source-of-truth rows in one engine — retrieval without a second vector database.
THE STATUS QUO
The RAG stack keeps growing: a vector database, a keyword index, the operational database, and glue code shuttling records between them — with three consistency stories.
HOW EzraDB DOES IT
Store embeddings beside the rows they describe; query with <-> (L2), <#> (inner product), or <=> (cosine) — your existing pgvector code paths work.
ORDER BY embedding <-> $1 LIMIT k joins directly against permissions, tenants, and metadata — no post-filtering round-trip.
Combine keyword relevance (tsquery, ts_rank) with vector similarity in one query plan — hybrid retrieval without fusing two systems.
Chunk metadata lives in JSONB; RLS scopes retrieval per tenant so the model never sees the wrong customer’s context.
Re-ranking, score blending, and prompt assembly run next to the data — ship the function, not the corpus.
Approximate nearest-neighbor indexing for large corpora.
*In development — not yet production-ready.
IN PRACTICE
Retrieval is a query, not an architecture. Keep it where the data already lives.
CREATE TABLE items (id int, embedding vector(3));
SELECT id FROM items ORDER BY embedding <-> '[3,3,3]' LIMIT 5; -- <-> L2, <#> inner, <=> cosine
MORE WAYS TEAMS USE EzraDB