Loading post…
DatabricksPhilipp TiefenbacherBenchmark
Sizing Lakebase Search: lessons from a real app and 4 million passages
Summary
Slide Hub, an internal Databricks app for slide search, uses Lakebase Postgres with Lakebase Search extensions (lakebase_vector and lakebase_text) to run hybrid vector and BM25 search on the same database as application data. The app stores 23k slides and indexes up to 4M passages from the MIRACL English corpus. Benchmarking shows that below 8 Compute Units (CU), Lakebase Postgres is the bottleneck; above 8 CU, the app’s worker count limits throughput. Candidate pool size significantly affects cold-start latency: 200 candidates preserves 90.5% of top-10 results while touching a third of the pages of 1,000 candidates. A 14-minute load test cost 0.13, with Lakebase compute billing only while active. For production, a 0.5 CU minimum costs ~ 31-40/month and avoids cold-start delays.
Context
The post is for developers and architects building apps on Databricks who want search inside Lakebase Postgres. It assumes knowledge of SQL and PostgreSQL basics. The post uses Slide Hub, an internal Databricks app for slide search, as a real app to benchmark Lakebase Postgres search performance under actual workload.
Approach / What changed
The post uses Lakebase Search extensions (lakebase_vector for ANN index with IVF partitioning and RaBitQ quantization, lakebase_text for BM25 index) to run hybrid search within Lakebase Postgres. It benchmarks by varying compute units (CU) and app worker counts, measuring requests per second and latency. It also experiments with candidate pool sizes (40, 100, 200, 1000) to measure cold-start latency and result overlap.
Takeaways
Below 8 CU, Lakebase Postgres is the bottleneck; above 8 CU, the app’s worker count limits throughput. Scale Lakebase Postgres first, then the app.
A candidate pool of 200 preserves 90.5% of top-10 results while touching a third of the pages of 1,000 candidates, reducing cold-start latency significantly.
Lakebase Postgres bills compute only while active; a 0.5 CU minimum costs ~$31-40/month and avoids cold-start delays. A 14-minute load test cost $0.13.
FAQ
What is the optimal candidate pool size for Lakebase Search?
200 candidates is recommended; it preserves 90.5% of top-10 results while reducing pages touched by two-thirds compared to 1,000 candidates. Users rarely page past 200 results.
How does Lakebase Postgres compute sizing affect search performance?
Below 8 CU, adding CU improves throughput; above 8 CU, the app's worker count becomes the bottleneck. At 16 CU with a MEDIUM app, throughput increased only 4% over 8 CU.
What is the cost of running Lakebase Search for a production app?
A 0.5 CU minimum costs about $31-40/month at list price. A 14-minute load test cost $0.13, with Lakebase compute billing only while active.
Source and freshness
- Source
- databricks.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.