Announcing Lakebase Search: agent-native retrieval built into Lakebase Postgres

2026-06-16 · Source: Databricks · Field: Technology & Digital — Artificial Intelligence & Machine Learning, Cloud Computing & IT Infrastructure, Data Science & Analytics · Depth: Advanced, medium

Summary

Lakebase Search, in beta on AWS/Azure, integrates hybrid vector and full-text retrieval directly into Lakebase Postgres via `lakebase_vector` and `lakebase_text` extensions. This architecture is optimized for agent-native operational workloads, demanding instant real-time search. It uses a serverless Postgres OLTP design, storing data in cheap cloud object storage with a tiered cache, reducing costs from ~\$3,000/TB/month (RAM) to ~\$20/TB/month (object storage). `lakebase_vector` achieves 32x compression, enabling a 100M-vector index to fit under 10GB RAM, scaling to 1B+ vectors. `lakebase_text` provides native BM25 ranking without GIN index memory bloat. Benchmarks on LAION-100M (100 million 768-dimensional vectors) show 0.955 recall@10 with 30 ms P99 latency and 51 QPS on a 192 GB instance, outperforming traditional pgvector. This consolidates agent memory and context into a single backend, supporting continuous search experimentation and dedicated retrieval engines.

Key takeaway

For AI Architects designing agentic applications, Lakebase Search offers a compelling solution to consolidate retrieval and memory. You can eliminate separate vector stores and transactional databases, simplifying your stack and reducing operational costs significantly. By utilizing its tiered storage and native Postgres extensions, you can achieve high-performance, real-time search on fresh data, even with bursty workloads. Consider adopting Lakebase Search to streamline your agent infrastructure and enable continuous search experimentation.

Key insights

Agent-native search requires instant, real-time retrieval on a single, cost-effective, tiered storage backend.

Principles

• Agent search is an operational read/write workload.
• Vector search bloat demands tiered storage solutions.
• Index layout must optimize for tiered storage hierarchy.

Method

Lakebase Search uses `lakebase_vector` for 32x compressed vector indexes and `lakebase_text` for BM25 full-text, both optimized for tiered cloud object storage within Postgres.

In practice

• Consolidate agent memory and context into one Postgres backend.
• Provision isolated search corpora per agent or user.
• Branch multi-terabyte datasets instantly for experimentation.

Topics

• Lakebase Search
• Agentic AI
• Vector Databases
• Postgres Extensions
• Tiered Storage
• Hybrid Search
• BM25 Ranking

Best for: CTO, VP of Engineering/Data, Director of AI/ML, AI Engineer, MLOps Engineer, AI Architect

Related on AIssential

• Agents need vector search more than RAG ever did — AI agents significantly increase retrieval demands, making purpose-built vector search infrastructure more critical, not less.
• Ghost AI let's AI Agents build disposable worlds — AI agents require isolated, disposable database forks for safe, parallel experimentation, akin to code versioning, to prevent data corruption and enable clean comparison.
• Building Cost-Efficient Agentic RAG on Long-Text Documents in SQL Tables — An Agentic RAG architecture can integrate LLMs with existing SQL databases for hybrid structured and semantic queries.
• A semantic memory layer for local AI agents — no vector DB, one file, runs on CPU — A lightweight, local semantic memory solution for AI agents avoids complex vector databases for smaller datasets.
• AI 101: Agentic Vector Databases – What Is That? — Vector databases are evolving from passive retrieval to active components supporting AI agent reasoning, memory, and dynamic knowledge management.
• Building Intelligent Search with Amazon Bedrock and Amazon OpenSearch for hybrid RAG solutions — Hybrid search combining semantic and text-based methods significantly enhances AI assistant accuracy and adaptability.

Open in AIssential →

Editorial summary, takeaway, and curation by AIssential. Original article published by Databricks.