Lakebase Postgres separates compute from durable storage, making efficient compute-side caching essential for high-throughput, low-latency workloads. In this update, we share how larger shared buffers and huge pages help keep more hot data in DRAM, while reducing pressure on the storage layer.
Key highlights
- A more efficient cache path: Traditional Postgres can double-buffer data in shared buffers and the operating system page cache. Lakebase uses a local file cache alongside Postgres shared buffers, while the durable storage layer remains authoritative.
- Larger shared buffers for fixed-size computes: For fixed-size computes with 80 or more CUs, Lakebase now disables the local file cache and sizes shared buffers to 75% of available DRAM. This keeps more frequently accessed pages in the lowest-latency cache tier.
- Huge pages reduce memory overhead: Large shared buffers can create significant page-table and translation overhead across Postgres processes. Dedicated 2 MB huge pages reduce page-table size and TLB pressure; benchmark testing showed up to roughly 40% lower tail read latency and up to 30% lower CPU utilization.
- Production results show meaningful gains: Early rollout examples included about 2ร higher throughput with 5ร fewer storage reads on one endpoint, about 1.3ร throughput on another, and a workload that used 5ร less CPU while doubling throughput. Results depend on workload and access patterns.
- Autoscaling is next: The current improvements target fixed-size computes because shared buffers are not yet dynamic. The next phase is bringing larger shared buffers to autoscaling computes, including dynamically resizing the buffers and the huge-page backing as compute changes size.
๐ Read the full post here
