Databricks tests Lakebase Search on a real slide app and finds where it hits limits

Hybrid search inside the app database

Slide Hub is an internal Databricks app that field engineers use to find and reuse slides from about 700 internal presentations. A search bar finds single slides by meaning and by keyword, and a Model Context Protocol (MCP) server gives AI agents the same search. The app stores its slides, votes, search telemetry and change history in Lakebase Postgres.

Lakebase Search became generally available in September, according to Databricks. It is a set of Postgres extensions, so it runs next to the application tables and does not require copying data to a separate search system. lakebase_vector stores embeddings and supports the lakebase_ann index for approximate nearest neighbor search. lakebase_text supports the lakebase_bm25 index for keyword ranking. The ANN index uses IVF partitioning and RaBitQ quantization, which compresses each vector to about 1 bit per dimension.

Slide Hub's 23k slide rows sit in the same serverless Lakebase Postgres instance as the votes, telemetry, change history and previews. One SQL statement runs the whole ranking policy. It takes 200 candidates from each method, fuses them with Reciprocal Rank Fusion at k=60, applies a similarity gate of 0.70, and filters results to assets the user may see.

Where the load limit sits

A search request uses two separate computes: Lakebase Postgres and the Databricks Apps compute that runs the web server. The test changed one side at a time and raised the number of simulated users in steps. Results at 500 users:

• 1 CU, MEDIUM app with 2 workers: 196 req/s, p50 1.8 s
• 4 CU, MEDIUM app with 2 workers: 219 req/s, p50 1.6 s
• 8 CU, MEDIUM app with 2 workers: 336 req/s, p50 1.0 s
• 16 CU, MEDIUM app with 2 workers: 349 req/s, p50 1.0 s
• 16 CU, LARGE app with 4 workers: at least 662 req/s, p50 343 ms

Up to 4 CU, the database is the limit. At 1 CU the search statement averaged 146 ms and read 14.9M pages from storage, with a file cache of 1.5 GB. At 8 CU it averaged 34 ms with a 12 GB cache, and throughput rose about 50%. From 8 CU, the app becomes the limit: 16 CU with the same MEDIUM app added only 4%. At 16 CU with a LARGE app, the load generator was the limit.

The connection pool still mattered. At 50 users the app reached 45 req/s and 2.4 s p95 without it, and 85 req/s and 0.7 s p95 with it. The embedding cache made no measurable difference under load.

Smaller candidate pools, cheaper cold starts

The number of candidates per method sets how many pages a query touches, and on a cold cache that sets latency. Slide Hub originally shipped with 1,000 candidates. The test measured 20 public queries:

• 40 candidates: cold 127 ms, repeat 5.0 ms, 5,655 pages, top-10 overlap 74.5%
• 100 candidates: cold 240 ms, repeat 7.9 ms, 7,355 pages, top-10 overlap 89%
• 200 candidates: cold 387 ms, repeat 11.7 ms, 10,401 pages, top-10 overlap 90.5%
• 1,000 candidates: cold 740 ms, repeat 35.3 ms, 28,972 pages, top-10 overlap 100% (the reference)

Because users rarely page past 200 results, Slide Hub now ships 200. Measured end to end from a job in the same cloud region, a cold search at 200 candidates took 2.9 s and a repeat search took 40 ms. About 1 s of the cold time is the endpoint waking up, and the first query on a new connection pays about 75 ms of planning.

What it means for builders

Databricks says the first step is to size the query, then scale Lakebase Postgres until the app workers become the limit, and only then scale the app. Below 8 CU, adding database capacity helps; from 8 CU, more app workers help.

On cost, Lakebase Postgres bills compute only while it runs. A 14-minute load test serving 109k requests used just $0.02 of Lakebase Postgres compute, according to Databricks. To avoid cold starts, the company recommends a $31~40/month always-on 0.5 CU floor as the production baseline. The source also describes scale tests from 1M to 4M rows of the public MIRACL English corpus, but the provided text ends before those results.