Hybrid Search Explained: Do You Really Need a Separate Vector Database for AI?
What Databricks Lakebase Search teaches aspiring data and AI engineers about retrieval, database architecture, and production systems.
1. Your AI chatbot works. Until someone asks a real question.
Imagine you're a junior data engineer working on an internal AI assistant.
Your company wants employees to ask questions about customer orders, company policies, and invoices.
You've built a Retrieval-Augmented Generation (RAG) system. It searches company documents and passes relevant information to a Large Language Model (LLM) to generate an answer.
During your demonstration, everything works.
Then someone asks:
"What is the refund status for order REF-2026-1847?"
Your system retrieves a general refund policy but misses the document containing that specific order number.
The AI generates a convincing explanation, but it's based on incomplete information.
What went wrong?
You might think you need a better AI model. But the real problem could be how your application retrieves information.
This is where hybrid search becomes useful.
And a recent Databricks announcement raises an interesting question:
Do AI applications really need a separate vector database, or can PostgreSQL handle operational data and search together?
Let's explore what changed, how the technology works, and what aspiring engineers can learn from it.
2. What did Databricks announce?
On September 28, 2026, Databricks published an engineering article introducing the architecture behind Lakebase Search.
Lakebase Search reached general availability on AWS and Azure in September 2026. The official release notes date this milestone September 18.
Lakebase is Databricks' managed PostgreSQL-based operational database. Operational databases store information applications frequently read and modify, such as customers, orders, and account records.
Lakebase Search introduces two important extensions:
lakebase_vector — Vector search
This supports Approximate Nearest Neighbor (ANN) search, which efficiently finds embeddings similar to a search query.
lakebase_text — Keyword search
This adds BM25 relevance ranking, a method for identifying documents that best match searched words or terms.
Both capabilities work within PostgreSQL and can be combined with SQL queries, filters, and joins.
Separately, Databricks' September 28 release notes introduce lakebase_tokenizer, which supports configurable text processing, including normalization, stopwords, synonyms, and stemming.
These capabilities are interesting because teams may be able to combine operational records and search without maintaining an entirely separate search database.
However, the underlying concepts aren't new.
PostgreSQL already supports full-text search, and the open-source pgvector extension supports vector similarity search.
The important development is how Databricks has implemented and scaled these capabilities in its managed database architecture.
3. Understanding keyword, vector, and hybrid search
Before looking at Lakebase's architecture, we need to understand three retrieval methods.
Keyword search: Finding exact information
Imagine someone searches for:
"Invoice INV-9041 payment status"
A keyword search system looks for matching terms in documents.
One widely used relevance-ranking method is BM25.
BM25 considers several factors, including:
How frequently a term appears in a document.
How common that term is across the entire document collection.
The length of the document.
For example, the invoice identifier INV-9041 may be more useful than a common word such as "payment."
Keyword search is valuable when exact wording, product codes, error messages, or document identifiers matter.
However, it can struggle when someone uses different words to describe the same idea.
Vector search: Finding similar meanings
Consider another question:
"Can I get my money back if my parcel never arrives?"
The relevant document might say:
"Customers may request reimbursement for undelivered shipments."
The wording differs, but the meaning is similar.
Vector search addresses this problem through embeddings.
An embedding is a numerical representation generated by a model. Texts with related meanings are intended to produce vectors that are relatively close in a mathematical space.
A vector search system compares these representations to identify similar content.
This makes vector search useful for natural-language questions.
But similarity creates another challenge.
A document discussing a general refund policy may be semantically similar to a question about a specific order without containing the correct order information.
Semantic similarity does not guarantee factual relevance.
Hybrid search: Using both approaches
Hybrid search combines keyword and vector retrieval.
For example:
"What's the refund deadline for order REF-2026-1847?"
Keyword search can help locate the exact order identifier.
Vector search can retrieve documents discussing refund deadlines, even when they use different terminology.
The application combines both result lists into a final ranking.
One common technique is Reciprocal Rank Fusion (RRF).
RRF awards each result a score based on its rank in the different lists. Results appearing near the top of multiple lists receive stronger combined scores.
Databricks' Lakebase documentation demonstrates RRF using a ranking constant of 60.
However, hybrid search is not guaranteed to outperform either method individually.
If the combined search introduces irrelevant candidates, retrieval quality may decline. Engineers still need to evaluate the results.
4. How did companies traditionally solve this problem?
Consider a company building an AI customer-support application.
A common architecture might contain:
PostgreSQL
Stores customers, orders, payment records, and access permissions.
Elasticsearch or another search service
Supports keyword-based document retrieval.
A vector database
Stores embeddings for semantic search.
Data synchronization pipelines
Transfer updates from the operational database into the search systems.
When an order changes, the company needs those updates to reach the relevant indexes.
This may involve Change Data Capture (CDC), which detects database changes, or Extract, Transform, Load (ETL) pipelines.
The architecture can work well, particularly at scale.
But it creates responsibilities.
What happens if an order changes in PostgreSQL but the search index still contains the previous information?
What happens if synchronization fails?
How do you ensure the search service respects customer access permissions?
And who maintains the additional infrastructure?
These aren't reasons to reject specialized databases.
They are costs and risks engineers should understand before introducing another system.
5. What does Lakebase Search improve?
The central idea behind Lakebase Search is to bring keyword and vector retrieval closer to operational data.
Instead of maintaining separate databases for every retrieval method, applications may perform searches and join the results directly against PostgreSQL tables.
For example, an AI assistant could retrieve relevant refund documents while filtering orders by customer ID and status.
This potentially reduces duplicated data and the synchronization pipelines required to maintain separate search systems.
Databricks also describes specific performance techniques.
More efficient vector indexes
Lakebase uses hierarchical Inverted File (IVF) clustering and RaBitQ binary quantization.
In simple terms, IVF organizes vectors into groups so a query can examine promising groups rather than searching every vector.
Quantization compresses vector representations, reducing the amount of information that must be processed during candidate selection.
The system can then rerank shortlisted candidates using more precise representations.
These techniques aim to reduce memory requirements and unnecessary storage reads.
Faster keyword retrieval
Lakebase's BM25 implementation can skip blocks of indexed documents that cannot contribute to the highest-ranked results.
This reduces unnecessary ranking work.
Performance claims need context
Databricks reports 97% recall with 71-millisecond P99 latency in a benchmark involving 100 million vectors.
Here, recall measures how many of the true nearest neighbors the search system successfully retrieves.
P99 latency means 99% of measured requests complete within the stated duration or less.
These are vendor-reported benchmark results under particular test conditions.
They don't prove Lakebase will deliver equivalent performance for every dataset, application, or workload.
The broader engineering lesson is more useful:
Database architecture should be evaluated using retrieval quality, latency, operating cost, and maintenance complexity—not benchmark headlines alone.
6. Limitations: A simpler architecture still needs engineering
Integrated search sounds attractive, but it doesn't remove every operational challenge.
Search indexes still require maintenance
One important limitation appears in the Lakebase documentation.
Its BM25 implementation calculates corpus-wide statistics when the index is built, rather than updating those statistics incrementally.
These statistics help determine which terms are important across the document collection.
As documents are added or changed, the statistics may become outdated.
Rebuilding the index may therefore be necessary to refresh ranking statistics, depending on the workload and required relevance quality.
This distinction matters.
Even if you eliminate a separate synchronization pipeline, you haven't eliminated index maintenance.
Deployment requires planning
Lakebase Search requires PostgreSQL 16 or later.
Enabling the capability restarts the project's compute resources, disconnecting active sessions.
It also cannot be disabled once enabled.
Production teams should therefore evaluate compatibility, test in a non-production environment, and plan the deployment appropriately.
Mixed workloads still need monitoring
Combining transactional and search workloads does not eliminate competition for compute resources.
Teams must continue measuring query latency, throughput, and resource utilization.
Approximate search involves trade-offs
ANN indexes improve search efficiency by examining selected candidates rather than necessarily checking every vector.
As a result, they can miss some of the true nearest neighbors.
For applications requiring exceptionally high retrieval completeness, teams must carefully evaluate the accuracy-versus-performance trade-off.
Search is not a security mechanism
Finding a relevant document does not establish that a user is authorized to see it.
Access restrictions must be enforced during retrieval, before unauthorized content can reach an AI model.
7. When should companies choose a separate search service?
Lakebase Search doesn't make dedicated search platforms obsolete.
Consider three situations.
Situation A: Search closely depends on operational records
A customer-service application frequently joins search results with live customer orders and permissions.
Integrated PostgreSQL search may reduce architectural complexity.
Situation B: A company already operates specialized search infrastructure
An organization might rely on advanced search capabilities, independent scaling, or an established Elasticsearch deployment.
Replacing it could create migration costs without delivering sufficient improvement.
Situation C: A team wants managed retrieval with less tuning
Databricks distinguishes Lakebase Search from its separate managed AI Search offering.
For teams that prioritize managed retrieval and reduced manual optimization, a dedicated managed service may be more suitable.
The decision depends on workload requirements, existing infrastructure, operational expertise, and cost.
The newest technology is not automatically the appropriate architecture.
8. A realistic enterprise example: Insurance policy assistance
Imagine an insurance company with thousands of customer policies.
An employee asks:
"Does policy HOME-7821 cover water damage from a leaking pipe?"
The system needs several types of information.
First, it must identify the customer's active policy.
Next, it must retrieve clauses relating to water damage, exclusions, and relevant policy versions.
Keyword search helps identify the exact policy code.
Vector search helps find related clauses, even if they describe water damage using different terminology.
Hybrid search combines these signals.
The application then filters the results using customer access permissions and verifies that the documents belong to the correct policy version.
Finally, an AI assistant can summarize the relevant passages and provide source references.
For uncertain or consequential decisions, the system should allow employees to review and escalate the result.
This illustrates a broader point.
Building an enterprise AI assistant requires more than choosing an LLM.
Engineers must also understand data modeling, retrieval, authorization, document freshness, evaluation, and human oversight.
9. Build a small hybrid-search project
You don't need Databricks to practise the fundamentals.
A useful learning project is a searchable internal-support knowledge base.
Step 1: Prepare sample data
Create 100 fictional company documents covering refunds, shipping, invoices, and account problems.
Include exact identifiers, such as invoice numbers and order references.
Prepare 20 test questions, identifying which documents should be retrieved for each question.
Step 2: Build keyword search
Use PostgreSQL's built-in full-text search functionality.
You can rank documents using ts_rank or ts_rank_cd.
Important: These PostgreSQL functions do not implement BM25.
Your experiment will demonstrate lexical retrieval, but its ranking scores are not equivalent to Lakebase's lakebase_text BM25 scores.
If you want to evaluate BM25 specifically, introduce a separate BM25 implementation as another experimental baseline.
Step 3: Build vector search
Use Python and a sentence-embedding model to generate vectors for your documents.
Store them in PostgreSQL using pgvector.
Then run similarity searches using the same test questions.
For only 100 documents, exact vector search is sufficient. ANN indexes become more interesting when evaluating larger datasets and performance constraints.
Step 4: Combine the results
Run keyword and vector searches independently.
Collect the top-ranked results from each method.
Implement RRF to combine them into a hybrid ranking.
Now you have three retrieval methods to evaluate:
PostgreSQL native keyword search.
Vector similarity search.
Hybrid retrieval using RRF.
Step 5: Measure retrieval quality
Use Recall@5.
This metric measures the proportion of known relevant documents returned within the first five results.
For example, if a question has four relevant documents and the top five results contain three of them, Recall@5 is 75%.
Calculate the metric for every test question, then aggregate the results.
Also record latency and inspect incorrect results.
You may discover that hybrid retrieval performs better for mixed questions but provides little benefit for simple exact lookups.
That's a meaningful engineering finding.
The objective isn't to prove hybrid search always wins.
The objective is to understand when each method works and how to evaluate the trade-offs.
This project does not benchmark Databricks Lakebase Search itself. It demonstrates the underlying retrieval principles using independently available tools.
10. What skills does this project demonstrate?
A well-documented project can demonstrate capabilities beyond basic programming.
SQL and data modeling
You understand how documents, identifiers, and application records are represented and queried.
Information retrieval
You can explain the strengths and weaknesses of keyword, vector, and hybrid search.
AI engineering
You understand how retrieval supplies evidence to a RAG application rather than relying entirely on an LLM's generated knowledge.
Evaluation
You can create test datasets, measure retrieval quality, and investigate failures.
Architecture judgment
You can discuss whether introducing another search system is justified by actual requirements.
If you publish the project on GitHub, include your methodology, reproducible setup, evaluation results, failed experiments, and limitations.
For early-career engineers, demonstrating how you investigated a problem can be more informative than simply displaying a working chatbot.
11. What should you learn next?
Start with PostgreSQL queries, joins, and full-text search.
Then learn embeddings and vector similarity.
Once you understand both approaches, implement hybrid ranking and build an evaluation dataset.
After that, explore more advanced production concerns:
Index freshness and rebuilding.
Authorization filters.
Search latency under concurrent workloads.
Query observability and failure handling.
Operational costs and infrastructure trade-offs.
If you're considering dedicated vector databases or managed search services, compare them using the same representative application requirements.
Databricks Lakebase Search is an interesting development because it demonstrates how operational databases are expanding their retrieval capabilities.
But the most valuable takeaway isn't the name of a new database extension.
It's learning to recognize unnecessary architecture complexity while understanding which specialized components still serve a purpose.
Before adding another database to your AI system, ask three questions:
What specific problem does this additional system solve?
What operational complexity will it introduce?
How will we measure whether the architecture is better?
Being able to answer those questions is an important step toward becoming an engineer who can design, evaluate, and maintain production AI systems.
Sources and further reading
Primary Databricks sources
Databricks Engineering Blog (September 28, 2026). Lakebase Search: State-of-the-art full text and vector search for Postgres.
https://www.databricks.com/blog/lakebase-search-state-art-full-text-and-vector-search-postgresDatabricks. Lakebase Release Notes. Includes the September 18 general-availability announcement and September 28 tokenizer update.
https://docs.databricks.com/aws/en/release-notes/lakebaseDatabricks. Lakebase Search Documentation. Includes architecture, deployment requirements, BM25 index behavior, and RRF examples.
https://docs.databricks.com/aws/en/oltp/projects/lakebase-search
Technical references
pgvector — Open-source PostgreSQL vector similarity search extension.
https://github.com/pgvector/pgvectorPostgreSQL — Text Search Controls and Ranking.
https://www.postgresql.org/docs/current/textsearch-controls.htmlElastic — Reciprocal Rank Fusion Reference.
https://www.elastic.co/docs/reference/elasticsearch/rest-apis/reciprocal-rank-fusion
Editorial note: The insurance scenario and learning project are illustrative examples. Product capabilities and deployment requirements are drawn from official sources. Architectural recommendations are engineering interpretations, not claims of universal performance or suitability.
