The cache has to be about as large as the index
A Databricks engineering post on October 15 uses two workloads to size Lakebase search. The page time is 00:06 UTC, 08:06 in Beijing. One workload is the internal app Slide Hub: about 700 internal decks and 23,000 slides, with search for people and for agents through MCP. The other is subsets of the MIRACL English Wikipedia corpus, measured at 1 million, 2 million, and 4 million passages.
They call cache size divided by vector-index size the cache ratio. On a skewed query mix, a ratio of 0.07 kept about 45 percent of pages in cache, 0.57 kept about 86 percent, and 1.14, where the index just fits, kept about 97 percent. A uniform mix sits a few points lower because it almost never repeats. The post says a cache about the size of the index serves about 95 to 98 percent of pages without storage.
[1]
Fewer candidates, and most of the top ten stay
Slide Hub used to take 1,000 candidates from each method. At 200, a cold cache took 387 milliseconds, a repeat took 11.7 milliseconds, 90.5 percent of the top 10 still matched the 1,000-candidate result, and the query read about a third as many pages. At 40 candidates, top-10 overlap fell to 74.5 percent. They now ship 200.
In the same cloud region, an end-to-end cold search at 200 candidates took 2.9 seconds, about 1 second of that waiting for compute to wake from zero. A repeat took 40 milliseconds.
[1]Two cents is this 14-minute ramp
One in-region ramp ran for 14 minutes and cost 13 cents at list price: 11 cents for the app and 2 cents for Lakebase Postgres. Compute autoscaled between 0.5 and 1 compute unit and used 0.21 compute-unit hours. Up to 1,000 users, the ramp served 109,602 requests, and the post says there were no errors.
They recommend a production floor of 0.5 compute units rather than scaling to zero. At list price that is about 31 to 40 dollars a month, to avoid about 1 second of wake-up and an empty cache. Slide Hub itself still scales to zero, because its users can accept a slow first search after idle time. Lakebase was about 1 percent of that internal app's 30-day bill.
[1]The default setting finds about three quarters
The index is approximate. Recall@10 is the share of the true 10 nearest passages that the index also returns. At the default probe count, 1 million, 2 million, and 4 million passages scored 0.74, 0.75, and 0.75. On 4 million passages, the default 109 probes returned 0.74 in 3 milliseconds, and 2,000 probes returned 0.95 in 49 milliseconds.
An index built in quality mode reached 0.80 at those default probes in 3 milliseconds, and 0.97 at 2,000 probes in about the same time. The build for 4 million passages at 16 compute units took 52 minutes. The post says recall depends on the data and the embedding model, and that the probe count has to be measured again for the app.
[1]