Why the RAG Stack Keeps Splitting Into Three
Most RAG services sprawl across three components: an operational DB for the source records, a dedicated vector DB for embeddings, and a search engine for keyword matching. Each piece carries its own schema and its own indexing cadence, so a single document change forces three separate updates — and that seam is exactly where operational cost and failure surface grow together. The Lakebase Search beta that Databricks unveiled at Data + AI Summit 2026 (June 15–18) is worth a hard look through one specific lens: folding those three pieces into a single Postgres engine.
What Compression Changes: From a RAM Constant to a Storage Variable
Lakebase Search uses RaBitQ-based 32x compression to fit a 100-million-vector index — which previously demanded roughly 300GB of RAM — into under 10GB, while scaling past a billion vectors. The accompanying lakebase_text extension ships an object-storage-optimized index that replaces GIN, plus native BM25. Because both extensions run in the same engine, hybrid search that fuses vector similarity and keyword scores through RRF works in a single SQL statement, and the types stay standard pgvector and tsvector, so Postgres compatibility remains 100%.
Consolidate or Not: The Bar to Set Before Collapsing Three Stacks
Consolidation reduces component count; it does not raise search quality on its own. Pin down what you remove and what you gain in numbers first, or the decision has no footing. Set targets on three axes: the RAM and storage cost the index occupies, the sync lag between source and index, and the answer-inclusion rate (recall@k) of hybrid versus single-mode search. A workable starting line — for 100M vectors, resident index memory under 10GB, source-to-index sync lag p95 within 5 seconds, and hybrid securing at least +5pp over vector-only at recall@10 — goes into a table you fill in the same cells before and after consolidation.
With the bar set, work backward from the failure patterns. The most common incident in a three-piece layout is sync drift between the operational DB and the vector DB: the source updates, the embedding lags behind, and stale results ship. The second is a per-component failure domino, where one dead search-engine node collapses the entire hybrid ranking. The third is the cost blowup of a RAM-based index, whose resident memory grows linearly with vector count until it overwhelms the infra budget.
From a recovery standpoint, the advantage of a single engine is that the sync path itself disappears. When source and index live in the same transaction, drift cannot arise structurally, so tracing a stale result ends in one SQL surface rather than in cross-component batch lag. Still, keep a rollback route before you consolidate: run a dual-operation window so that if the hybrid SQL ranks worse than the legacy stack, you can revert to the previous search-engine routing.
Write the operations checklist as a migration order. First, shadow-replicate the read path to compare the hybrid SQL's recall@k offline against production traffic; next, dual-write the write path to confirm the sync lag vanishes; finally, promote read traffic 5% → 25% → 100%, watching recall and latency at each step. Load testing before consolidation must include resident memory at peak vector count, index-rebuild time, BM25 indexing lag under concurrent writes, and p95 query latency during RRF fusion. If your team already runs pgvector, the types carry over unchanged, so the lowest-risk path is a no-migration extension add — bolt on hybrid without reloading data and validate it there.
Treat recall regression as the cadence for continuous improvement. Each week, collect the top query types where hybrid fails to beat vector-only, tune the RRF weights and BM25 parameters, and log the number of components removed and the index cost saved as separate release-note lines. If you dropped pieces but the recall or cost curve did not improve, what you did was a rename-and-rearrange, not a consolidation.
Consolidation Decision Points at a Glance
Folding three stacks into one Postgres is a question of component count, not of search technique. RaBitQ 32x compression turns a RAM constant into a storage variable, a single transaction erases sync drift as a failure cause, the recall@k / resident-memory / sync-lag bars go into the same before-and-after table, and pgvector teams validate hybrid first via the no-migration extension path — together cutting both component count and TCO.
References
Announcing Lakebase Search: agent-native retrieval built into Lakebase Postgres — Databricks Blog