Databricks isolates app and database limits in its Lakebase Search sizing test
Databricks tests Lakebase Search on 1M to 4M rows, using a 23,000-row internal app as its baseline. A search request touches two computes, the app's and the database's, and either one can set the limit.
The Engineer · Build desk
Three figures. The Lakebase Search test runs up to 4M rows of a public corpus. Slide Hub, the app used as the baseline, has 23k slide rows. The low end of the test is 1M rows.
| Figure | Value | Note | Claim |
|---|---|---|---|
| Rows at the top of the test, public corpus | 4,000,000 rows | 15 | |
| Slide Hub's slide rows | 23,000 rows | 4 | |
| Low end of the test | 1,000,000 rows | 15 |
What happened
- Lakebase Search is a set of Postgres extensions that run next to the application tables, so the app does not copy data into a separate search system.
- Slide Hub's hybrid query takes 200 candidates from vector and keyword search each, then fuses the two lists with Reciprocal Rank Fusion at k=60.
- The database compute autoscales between 0.5 and 64 CU, and fixed-size computes go up to 112 CU.
- To find the limit, the test changes one side at a time, app compute or database compute.
Why it matters
- What it limits constraint Each Python worker holds 8 database connections, so one app instance opens at most 16 or 32, and a bigger database does not raise that ceiling.
- What it costs cost A workload that needs a 64 CU ceiling must carry a floor of at least 48 CU, and scale-to-zero stops at 32 CU, so the largest autoscaling computes do not get it.
- Who has to decide decision Slide Hub's 23k rows sit about 174 times below the 4M-row end of the test, so a team must place its own corpus against both ends before borrowing a compute size.
Slide Hub's ranking is one SQL statement, so its constants define the workload. [7] Each method returns 200 candidates, and Reciprocal Rank Fusion at k=60 scores a slide 1/(60 + rank) in each list. [5] At that k the scores are flat: rank 1 is worth about 0.0164 and rank 200 about 0.0038, a ratio near 4.3 to 1. [18] Deep candidates still count, so candidate depth is part of whatever a latency figure measures.
The 0.70 similarity gate is set for this embedding model, according to the post. [6] In our view a different model means a different gate.
Memory is the second variable. One CU is about 2 GB of RAM, and the Local File Cache can use up to 75% of the compute's memory. [9][10] That is about 1.5 GB of cache per CU. [19] A page outside the cache comes from storage and takes longer. [10] We'd expect latency to climb faster than row count once the index and hot rows outgrow that cache. That is the row count to look for between 1M and 4M.
The app side has its own ceiling. Each request embeds the query text in the app before it sends the SQL statement. [13] That work runs in a process whose size is fixed per app: up to 2 vCPU and 6 GB for MEDIUM, up to 4 vCPU and 12 GB for LARGE. [11] Slide Hub runs a single instance. [11]
Transfer is conditional. A figure from this test applies to an app with a similar row count, the same 200-candidate depth, a comparable embedding model and a comparable app tier. The post is written for developers who want to choose a compute size before production, and it covers how Slide Hub behaves under load, what it costs, and how Lakebase Search does on a public corpus at sizes between 1M and 4M rows. [15] Lakebase Search reached general availability in September. [2]
The post's text ends mid-sentence, at "It pins Lakebase Postgres at". [1] The compute sizes, latencies, throughput and costs it promises are not in that text, so any sizing drawn from it would be a guess.
What to watch
- The results section: latency and throughput at each CU size from 1M to 4M rows, and the row count where the cache stops covering the index.
- Whether MEDIUM versus LARGE app tiers, or 2 versus 4 workers, move the limit away from the database.
- Whether the post attaches a price to the compute sizes it tests, since it says it covers what the workload costs.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence50
- Adoption
- Not scored
- Hype gap+15
- Incentives65
- Confidence55
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The post's text ends mid-sentence, at 'It pins Lakebase Postgres at', before any compute size, latency, throughput or cost figure.
- [2]
Lakebase Search became generally available in September.
- [3]
Lakebase Search 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.
- [4]
Slide Hub's slide rows number 23k and sit in the same serverless Lakebase Postgres instance as the votes, telemetry, change history, previews and both indexes.
- [5]
Slide Hub takes 200 candidates from each search method and fuses the two lists with Reciprocal Rank Fusion at k=60: a slide scores 1/(60 + its rank) in each list, and the two scores add.
- [6]
A similarity gate of 0.70 rejects vector matches that are too far from the query to be useful for this embedding model.
- [7]
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.
- [8]
A search request uses two separate computes, and either one can set the limit.
- [9]
One Compute Unit (CU) allocates about 2 GB of RAM to the database, with its share of CPU and local SSD.
- [10]
Lakebase Postgres keeps recently read pages in a Local File Cache on the compute, which can use up to 75% of the compute's memory; a page not in the cache comes from storage, which takes longer.
- [11]
Databricks Apps compute is fixed in size per app: a MEDIUM app has up to 2 vCPU and 6 GB of memory, a LARGE app up to 4 vCPU and 12 GB. Slide Hub runs one app instance.
- [12]
Each Python worker process in the app holds a pool of 8 database connections, so 2 workers open at most 16 connections and 4 workers open at most 32.
- [13]
For each request, the app embeds the query text, sends one SQL statement to Lakebase Postgres, and returns the result.
- [14]
To find the limit, the test changes one side at a time.
- [15]
The post says it shows what limits Slide Hub under load, what it costs, and how Lakebase Search behaves from 1M to 4M rows of a public corpus, and that its numbers help readers choose a compute size before production.
- [16]
A Lakebase 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.
- [17]
Lakebase computes up to 32 CU can scale to zero.
- [18]
With RRF at k=60, rank 1 scores 1/61, about 0.0164, and rank 200 scores 1/260, about 0.0038, a ratio of about 4.3 to 1.
- [19]
The Local File Cache can reach about 1.5 GB per CU.
- [20]
The 4M-row end of the test is about 174 times Slide Hub's 23k rows.
- [21]
An autoscaling compute that must reach 64 CU needs a minimum of at least 48 CU, which is above the 32 CU limit for scale-to-zero.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- databricks.comSizing Lakebase Search: lessons from a real app and 4 million passages
1 article · October 14, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Database performance benchmarkingFollow
- Postgres hybrid searchFollow
- Vector Similarity SearchFollow