Lakebase Search Goes GA: Native Vector and Full-Text Search for Postgres

Why AI Agents Need Stronger Search

Retrieval is the backbone of RAG (Retrieval-Augmented Generation) and Agent workflows. When executing tasks, AI agents often need to pull relevant context from massive knowledge bases within milliseconds — any high-latency or low-recall query can skew reasoning results or stall the entire pipeline.

As workloads scale to millions or even billions of vectors, traditional solutions frequently buckle under three pressures: unstable latency, declining recall rates at scale, and costs that grow linearly — or worse — with data volume. Lakebase Search is positioned to address all three simultaneously: speed, accuracy, and cost efficiency at scale.

Merging Vector Search and BM25

One of Lakebase Search's key design decisions is embedding both vector search and BM25 full-text search directly into Postgres. These two retrieval methods represent complementary approaches: vector search excels at capturing semantic similarity, while BM25 delivers more consistent performance on exact keyword matching.

Unifying both within the same database engine means developers can build Hybrid Search capabilities in a familiar Postgres environment — without wiring together a separate vector database and search engine. For teams that have already built their data stack on Postgres, this reduces architectural complexity and eliminates the maintenance burden of keeping data in sync across systems.

Hybrid Search typically requires an extra step to merge results from both retrieval paths — techniques like RRF (Reciprocal Rank Fusion) are commonly used to combine vector similarity rankings with BM25 text relevance scores into a final result list. Having both search engines natively embedded in the same database means this merging logic can happen inside the engine itself, eliminating the overhead of orchestrating two separate services at the application layer, along with the network round-trips and result serialization that come with it. For latency-sensitive Agent pipelines, removing even a single cross-service call can shave tens of milliseconds off end-to-end latency.

Performance and Cost: Three Numbers from the Official Announcement

According to Databricks' official disclosure, Lakebase Search makes concrete, quantified commitments across several dimensions:

• A new frontier in price-performance, latency, and recall: The company claims Lakebase Search sets a new benchmark on VectorDBBench across price-performance, latency, and recall. VectorDBBench is a widely used industry benchmark for comparing vector databases, giving these claims a reasonable frame of reference.
• 4x cheaper than pgvector: For equivalent workloads, Databricks claims the cost is one-quarter that of running pgvector directly. Since pgvector is the most widely adopted open-source vector extension in the Postgres ecosystem, using it as the comparison baseline directly speaks to the same target audience.
• True pay-as-you-go: Zero compute cost when idle. This "pay only for what you use" model is particularly appealing for Agent applications with spiky or unpredictable traffic, eliminating the need to pay for idle resources.

It's worth noting that all figures above come from the vendor's own claims. Real-world performance should still be validated against your specific workloads and through independent benchmarking.

pgvector is an open-source PostgreSQL extension released by Andrew Kane in 2021, enabling vector storage and approximate nearest neighbor (ANN) search within standard Postgres tables. Its widespread adoption stems from zero-friction integration with existing Postgres tooling — but at very large scale, its IVFFlat or HNSW index performance is often constrained by single-machine memory and CPU resources, making horizontal scaling difficult. By using pgvector as the cost comparison baseline, Lakebase Search is essentially arguing: even if you've already chosen the "lightest" native Postgres approach, a managed service can still achieve better compute utilization — particularly by driving overall TCO (Total Cost of Ownership) down through zero compute cost during idle periods.

What This Means for Developers

For teams building AI agents or RAG systems, Lakebase Search offers a "stay within Postgres" technical path. If your data already lives in Postgres and you want better cost and performance than a self-managed pgvector setup, this GA release deserves a spot in your evaluation.

The real value lies in two areas: first, native fusion of vector and full-text search that reduces system integration friction; and second, a pay-as-you-go pricing model that ties costs directly to actual usage. For early-stage projects that are budget-conscious and can't reliably forecast traffic, this kind of elasticity matters.

That said, vendor benchmarks alone shouldn't drive your decision. The recommendation is to run small-scale validation on your actual business data — focusing on recall quality under your specific data distribution, P99 latency, and monthly costs under your real traffic patterns — before committing to a migration.

Summary

The GA of Lakebase Search reflects a clear trend in infrastructure today: vector search capabilities are migrating from standalone components into mainstream databases. Consolidating both semantic and keyword search within Postgres aligns with developers' preference for unified tech stacks, while offering a more competitive cost structure. Whether the claimed 4x cost advantage and benchmark leadership hold up across diverse real-world scenarios remains to be seen — and the broader community will be the ultimate judge.