Improving Lakebase Postgres compute cache

Summary

Lakebase Postgres uses disaggregated storage backed by object storage, so compute-side caching must deliver low latency and high throughput while avoiding inefficient memory use. Its original design paired a conservatively sized PostgreSQL shared buffer with a local file cache (LFC), but the roughly 1 GB shared-buffer cap pushed many hits to slower NVMe storage and could create double buffering. For fixed-size computes with CU >= 80, the new configuration disables the LFC and sets shared buffers to 75% of DRAM, using explicit 2 MB HugeTLB pages to control page-table and TLB overhead. Benchmark tests found huge pages reduced tail read latency by up to ~40% and CPU use by up to ~30%, while production examples reported doubled throughput, 5× fewer storage reads, or 5× lower CPU use. Work is underway to dynamically resize shared buffers and huge pages for autoscaling computes.

Takeaways

1. 1

   Fixed-size computes with CU >= 80 now use shared buffers sized to 75% of DRAM instead of the local file cache; an 80 CU endpoint should report shared_buffers as 20971520.

2. 2

   Using 2 MB huge pages reduced page-table sizes by a factor of 512; benchmark results showed up to ~40% lower tail read latency and up to ~30% lower CPU utilization.

3. 3

   Production examples included doubled throughput, storage GetPage/s falling from about 8K to 1.5K, and CPU use dropping from 20 cores to 4 on one workload.