Improving Lakebase Postgres compute cache

Lakebase Postgres uses a disaggregated storage model with object stores like S3, requiring efficient caching at two layers: distributed storage for high write throughput and compute-side caching for low-latency reads. The compute cache traditionally relies on Postgres shared buffers and the OS page cache, but this approach has limitations in disaggregated systems. Databricks has introduced incremental improvements to address these challenges, starting with fixed-size computes before advancing to autoscaling shared buffers.

Postgres shared buffers are static and limited to 1 GB in prior configurations, forcing many cache hits to rely on the slower local file cache (LFC). Databricks has now disabled the LFC on fixed-size computes with CU >= 80 and increased shared buffers to 75% of available DRAM. This change keeps hot data in the fastest memory layer, reducing latency and eliminating double buffering where cached data consumed memory in both shared buffers and the OS page cache.

The transition to larger shared buffers required addressing technical challenges, including the process per backend architecture in Postgres. Each backend maps shared buffers into its own address space, creating significant overhead with default 4 KB page sizes. Databricks implemented huge pages (2 MB) to reduce page table sizes and TLB miss penalties, resulting in up to 40% lower tail read latency and 30% reduced CPU utilization in benchmark tests.

Lakebase Postgres runs in lightweight VMs on bare-metal hosts, requiring consistent huge page support across the entire stack—from host reservation to hypervisor and guest kernel. Databricks has validated this implementation to ensure performance benefits are realized. Users can verify the new shared buffer size by running 'show shared_buffers' in a Postgres connection, with an 80 CU endpoint displaying a value of 20971520.