How lakebase architecture delivers 5x faster Postgres writes

Summary

Lakebase’s separation of Postgres compute and distributed storage removes the local-disk torn-page risk that necessitates full page writes (FPW) in traditional deployments. The change disables FPW on compute and moves full page image generation into the pageserver, which creates reset points after a configured number of WAL deltas while preserving bounded read reconstruction. In HammerDB TPROC-C tests, 32-vCPU throughput rose from 95,686 to 439,300 new orders per minute, while average WAL per transaction fell from 58KB to under 4KB, a 94% reduction. Production validation reported WAL reductions from 30MB/s to 1MB/s on a 56-vCPU project, p99 read latency improvements of 30% to 50%, and up to threefold regional storage p99 improvement. The rollout reached all Lakebase Serverless and Neon databases without restarts or customer interruption, using the existing XLOG_FPW_CHANGE mechanism.

Context

Traditional Postgres full page writes protect recovery from torn pages but can inflate WAL volume by up to 15x and become a bottleneck for write-heavy workloads. Disabling them without another mechanism would create long delta chains, increasing read latency and resource consumption.

Approach / What changed

Lakebase streams WAL to distributed safekeepers instead of relying on a local data directory, then disables compute-side full page writes and moves image generation to the pageserver. The storage layer generates images when a page exceeds a configured delta threshold, preserving bounded reads while reducing compute-side WAL traffic.

Takeaways

• On a 32-vCPU compute, HammerDB TPROC-C throughput increased from 95,686 to 439,300 NOPM, a 4.5x gain.
• Image generation pushdown reduced average WAL per transaction from 58KB to under 4KB and lowered production WAL from 30MB/s to 1MB/s on one 56-vCPU project.
• The change was rolled out fleet-wide without restarts or interruptions through the XLOG_FPW_CHANGE WAL record mechanism.

Related reading