Improving Lakebase Postgres Compute Cache on Neon, Part 1

Lakebase Postgres on Neon and Databricks has improved performance for large fixed-size compute instances by allocating up to 75% of DRAM to PostgreSQL shared buffers and backing them with explicit 2 MB huge pages, replacing much of the previous reliance on a local NVMe-based file cache. The change addresses limitations of traditional PostgreSQL caching, including duplicated data in operating-system caches, a former 1 GB shared-buffer cap, and memory-management overhead caused by PostgreSQL’s process-per-connection model. Production measurements report up to roughly twice the throughput, substantially fewer reads from distributed storage, lower latency, and in one case a reduction in CPU use from 20 to 4 cores; benchmark tests also found huge pages could reduce tail read latency by up to 40% and CPU utilization by up to 30%. The configuration is available for fixed computes of at least 18 CU on Neon and 80 CU on Databricks, while work is underway to make shared buffers and huge-page allocation dynamically scale for autoscaling computes. The team also notes a separate earlier optimization that moved full-page image generation to the storage tier, reducing write-ahead log volume and improving write throughput.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.