Announcement | Improving Lakebase Postgres compute cache

Tushar_Parekar — Wed, 16 Sep 2026 17:16:17 GMT

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

topic Announcement | Improving Lakebase Postgres compute cache in Lakebase Articles

Announcement | Improving Lakebase Postgres compute cache