---
title: "Zero downtime patching lakebase part-1 prewarming"
description: "Lakebase addresses the workload disruption caused by planned PostgreSQL maintenance, where a restart clears in-memory buffer and local file caches. Although the database can return in about one second at P99, the source reports a roughly 70% pgbench TPS reduction while caches warm, potentially causing timeouts. Lakebase uses stateless Postgres compute replicas and disaggregated shared storage to prewarm a replacement compute before a scheduled restart. The control plane transfers cached-page information, loads pages from shared storage, and follows relevant WAL from Safekeepers, while the current primary continues serving traffic. After prewarming, Lakebase promotes the new compute with PostgreSQL’s pg_promote without restarting the server; tests on 10 GB pgbench workloads found nearly instant throughput recovery, especially for read-only queries."
---

# Zero downtime patching lakebase part-1 prewarming

[Databricks](https://yomu.fyi/company/databricks) · Hans Norheim · Sep 18, 2026

**Type:** Problem & solution

## Summary

Lakebase addresses the workload disruption caused by planned PostgreSQL maintenance, where a restart clears in-memory buffer and local file caches. Although the database can return in about one second at P99, the source reports a roughly 70% pgbench TPS reduction while caches warm, potentially causing timeouts. Lakebase uses stateless Postgres compute replicas and disaggregated shared storage to prewarm a replacement compute before a scheduled restart. The control plane transfers cached-page information, loads pages from shared storage, and follows relevant WAL from Safekeepers, while the current primary continues serving traffic. After prewarming, Lakebase promotes the new compute with PostgreSQL’s pg\_promote without restarting the server; tests on 10 GB pgbench workloads found nearly instant throughput recovery, especially for read-only queries.

## Context

Planned database maintenance can disrupt workloads even when the restart itself is brief. Restarting PostgreSQL clears the buffer cache and local file cache, causing slower execution while data is read from storage and caches refill; the reported effect was about a 70% reduction in pgbench TPS and could lead to timeouts.

## Approach / What changed

Before a scheduled restart, Lakebase’s control plane starts an unbilled replacement Postgres compute in the background. It sends the current primary’s cached-page list, loads those pages from shared storage, and consumes relevant WAL from Safekeepers to keep the cache current. Once prewarming finishes, the old primary is shut down, the replacement is promoted with pg\_promote, and traffic is switched without restarting the database server.

## Takeaways

- A cold PostgreSQL restart can reduce pgbench throughput by about 70% while buffer and local file caches warm, making cache loss an availability concern when workloads begin timing out.
- Lakebase prewarms a stateless replacement compute using shared storage and relevant WAL from Safekeepers, without creating or billing for an additional full replica.
- In 10 GB pgbench tests, prewarming produced nearly immediate throughput recovery for both read-only and read-write workloads; the improvement was strongest for read-only traffic.

## FAQ

### Why can a fast PostgreSQL restart still disrupt workloads?

The server can return in about one second at P99, but restarting clears the buffer cache and local file cache. Until those caches refill from storage, throughput can fall sharply and workloads may time out.

### How does Lakebase prewarm a replacement without affecting the primary?

Lakebase starts a replacement compute in the background, loads the current cache’s pages from shared storage, and applies relevant WAL from Safekeepers. The current primary continues serving its workload during this process.

### Does prewarming require an additional full replica?

No. Lakebase uses stateless compute and disaggregated shared storage, so it does not require paying for an additional replica. The source says planned restarts of read/write endpoints use this process automatically, with read-only endpoints planned for a later extension.

**Tags:** [Caching](https://yomu.fyi/topic/caching), [Lakebase](https://yomu.fyi/topic/lakebase), [Postgres](https://yomu.fyi/topic/postgres)

- Source: [Databricks](https://www.databricks.com/blog/zero-downtime-patching-lakebase-part-1-prewarming)
- Source URL: https://www.databricks.com/blog/zero-downtime-patching-lakebase-part-1-prewarming
- Ingested by Yomu: 2026-09-17T14:12:53.040Z

[Read original post](https://www.databricks.com/blog/zero-downtime-patching-lakebase-part-1-prewarming)