Sizing Lakebase Search: lessons from a real app and 4 million passages

Sizing Lakebase Search: lessons from a real app and 4 million passages | Databricks Blog Skip to main content

Summary

Lakebase Search runs vector and BM25 keyword search as Postgres extensions inside the application database, so developers get hybrid search without maintaining a separate search system or a second transaction path.

Benchmarks show that sizing the Local File Cache to roughly match the vector index keeps 95~98% of pages in memory, dropping warm vector latency to single-digit milliseconds, while reducing the candidate pool from 1,000 to 200 preserves 90.5% of top-10 results at one-third the page reads.

Lakebase Postgres bills compute only while it runs, and a 14-minute load test serving 109k requests used just $0.02 of Lakebase Postgres compute, making a $31~40/month always-on 0.5 CU floor the recommended production baseline to avoid cold starts.

Slide Hub is an internal Databricks app. Field engineers use it to find and reuse slides from about 700 internal presentations: event talks, product decks, and architecture decks. 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 . We use Slide Hub as the baseline to benchmark Lakebase Postgres. It is a real app with a real use case and real users, so its numbers show how the database behaves under an actual workload. This post is for developers and architects who build apps on Databricks and want search inside the app's own Lakebase Postgres database. It assumes that you know SQL and the basics of PostgreSQL. If you plan a search bar or an agent tool on Lakebase Postgres, the numbers below help you choose the compute size before you go to production. This post shows how Slide Hub runs search inside Lakebase Postgres, what limits it under load, what it costs, and how Lakebase Search behaves from 1M to 4M rows of a public corpus. One database for the app and its search Lakebase Search became generally available in September. It is a set of Postgres extensions , so it runs next to the application tables. The app does not copy data to a separate search system. The developer does not maintain a second transaction path. Two CREATE EXTENSION statements enable the components. lakebase_vector stores embeddings , vectors of numbers that represent the meaning of a text, and supports the lakebase_ann index for approximate nearest neighbor (ANN) search. lakebase_text supports the lakebase_bm25 index for BM25, a standard method that ranks text by the query words it contains. lakebase_tokenizer is optional. The ANN index uses IVF partitioning, which groups similar vectors so a query reads only a few groups, and RaBitQ quantization, which compresses each vector to about 1 bit per dimension. BM25 scores text with the operator. Slide Hub’s 23k slide rows sit in the same serverless Lakebase Postgres instance as the votes, telemetry, change history, previews, and both indexes. The app reads the data and the indexes inside one connection and one permission model. The search query Slide Hub runs hybrid search . It combines vector search , which finds slides with a similar meaning to the query, and BM25 keyword search , which finds slides that contain the query words. Each method returns a short list of its best matches, the candidates . One SQL statement carries the whole ranking policy. It ranks each candidate list, fuses the two rankings, applies the app filters, and joins the votes. Search and app logic share one connection, one set of grants, and one commit. Slide Hub takes 200 candidates from each method. It fuses the two lists with Reciprocal Rank Fusion (RRF) at k=60: a slide scores 1/(60 + its rank) in each list, and the two scores add. A similarity gate of 0.70 rejects vector matches that are too far from the query to be useful for this embedding model. Title tiers add weight when the query matches a slide title. Notes receive weight 0.5. Scope filters restrict the result to assets the user has permission to see. What limits the app under load A search request uses two separate computes, and either one can set the limit. Lakebase Postgres compute runs the database. Lakebase Postgres sizes it in Compute Units (CU) . One CU allocates about 2 GB of RAM to the database, with its share of CPU and local SSD. A compute autoscales between a minimum and a maximum size from 0.5 CU to 64 CU, and the maximum can be at most 16 CU above the minimum. Fixed-size computes go up to 112 CU, and computes up to 32 CU can scale to zero .Postgres stores tables and indexes in 8 KB pages . Lakebase Postgres keeps recently read pages in a Local File Cache (LFC) on the compute. The cache grows with the CU size and can use up to 75% of the compute's memory. A page that is not in the cache comes from storage, which takes longer. Databricks Apps compute runs the Slide Hub web server. Its size is fixed per app. A MEDIUM app has up to 2 vCPU and 6 GB of memory, and a LARGE app has up to 4 vCPU and 12 GB. Slide Hub runs one app instance. Each Python worker process in it holds a pool of 8 database connections, so 2 workers open at most 16 connections and 4 workers open at most 32. For each request, the app embeds the query text, sends one SQL statement to Lakebase Postgrse, and returns the result. To find the limit, the test changes one side at a time. It pins Lakebase Postgres at one CU size and changes the app, or it keeps the app and changes the CU size. A load generator simulates users that send search requests, and it raises the number of users in steps. The list shows requests per second and the median latency (p50) at 500 users for each Lakebase Postgres size and app size. 1 CU, MEDIUM app with 2 workers: 196 req/s, p50 1.8 s 0.5 to 1 CU, LARGE app with 4 workers: 193 req/s, p50 1.6 s 2 CU, MEDIUM app with 2 workers: 201 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, Lakebase is the limit. A LARGE app with twice the workers and connections adds nothing at 1 CU. 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 cache of 12 GB, and throughput rose about 50%. From 8 CU, the app...