Databricks benchmarks Lakebase Search vector latency at 1M–4M passages
Cache-to-index ratio, not raw row count, is the variable that governs vector search latency, which is easy to miss when scaling a RAG corpus. Engineers running Lakebase or similar Postgres-backed vector stores can use the 11–23 ms warm p50 figures to set cache budgets before latency degrades. It offers concrete sizing guidance rather than vendor marketing.
Databricks benchmarked Lakebase Search across vector indexes holding 1 million to 4 million passages to see how latency scales with index size. The cache size relative to the vector index mattered more than row count. When the cache roughly matched the index size, 95–98% of page reads avoided storage and warm vector search p50 latency stayed between 11 and 23 ms. The takeaway is to size the cache alongside the vector index as datasets grow.
We benchmarked Lakebase Search on 1M to 4M passages to understand how vector search performs as the index grows. Here's what we learned 👇
Cache size relative to the vector index mattered more than row count. When the cache roughly matched the index, 95–98% of page reads avoided storage and warm vector search p50 latency stayed between 11 and 23 ms.
As datasets grow, sizing the cache alongside the vector index helps maintain low-latency search. https://t.co/Bb06flLWjV
