Massively parallel Postgres backups — PlanetScale📹 The future of AI infrastructure: optimize and shard your database with agents.Watch the talk
Navigation<br>Blog|Engineering<br>Table of contents «Close »Table of contents<br>The backup lifecycle<br>Reusing old backups<br>Replaying the WAL<br>Completing the cycle<br>The initial backup<br>Need for speed<br>What are backups used for?<br>What about MySQL?<br>Make it boring<br>PlanetScale Postgres is the fastest way to run Postgres in the cloud. Plans start at just $5 per month.<br>Learn more
Get the RSS feed
Massively parallel Postgres backups<br>Ben Dicken [@BenjDicken] | July 31, 2026<br>Every 12 hours, a backup system must turn the entire state of a busy database into a consistent, encrypted snapshot, with no impact to production queries.<br>Such backups are crucially important and simultaneously something that most engineers would rather never have to think about.<br>Just make the backup work.<br>Our goal at PlanetScale is to make taking, scheduling, managing, and restoring Postgres and MySQL backups effortless.<br>Though this is what our customers experience from the outside, achieving this internally requires careful orchestration of cloud infrastructure and DBMS tooling.<br>It's especially interesting to look at backups for sharded databases, which requires spinning up backup-specific nodes, pulling data from object storage, and WAL replay, all with massive parallelism. These techniques allow for petabyte-scale databases to be backed up in hours, at rates over 50 GB/s.<br>Here we take a behind-the-curtain look at how to effectively back up a sharded database with massive parallelism.<br>The backup lifecycle<br>Here is an example of a Neki (sharded Postgres) database with 8 shards, happily handling hundreds of thousands of queries per second of production traffic.<br>If sharding is a new concept to you, check out our recent post Making 768 servers look like 1 on how it all works. The first step in taking a backup depends on whether this is the very first backup or if we've taken one previously. We'll start with the steady-state case, which assumes a prior healthy backup already captured and stored in Amazon S3 (or similar object storage in other clouds).<br>Since a sharded Postgres database is many individual primary Postgres servers working together, we use regular Postgres backups as the building block for large-scale backups with Neki.<br>There are three ways to take backups in Postgres, which we've written about in detail previously. The best of the three, and the one that Neki uses, is combining filesystem backups with the replay of archived Write-Ahead Log (WAL). To summarize, the steps for this are:<br>Begin a full backup of the on-disk Postgres database files at time T1<br>The backup completes at time T2; between T1 and T2, rows on disk may have been mutated<br>Replay the write-ahead log modifications between T1 and T2 to correct mutated data<br>Store the final result in a distinct storage location like Amazon S3<br>We could complete these steps directly on the primary, or perhaps one of the traffic-serving replicas. The problem is that this task utilizes a significant amount of IOPS and compute, especially for a large database. Our goal should be to minimize the impact a backup will have on production query serving.<br>Because of this, we take a different approach. We spin up a brand new set of EC2 instances, one per shard, to manage the backups on.<br>These new instances will be responsible for the majority of the work in the backup. Because we operate these sharded databases in clouds like AWS and GCP, dynamically spinning up tens or hundreds of instances for short time slices to complete backups is achievable. It adds a small amount of cost, but is worth it to minimize negative production impact.<br>Reusing old backups<br>The next step is restoring the most recent backup to each shard. Prior backups are stored in object storage. Here we will use Amazon S3 as the example, but the same applies to other clouds (like GCS in Google Cloud). These are streamed directly from here.<br>This approach requires temporary compute and transfers each shard's data out of and back into object storage. We accept that cost for two important reasons:<br>Only recent WAL comes from the primary, minimizing production impact<br>Every cycle proves the previous backup can be restored and replayed<br>Once all the copying completes, these 8 servers have the exact state of each of the 8 shards from the previous backup, 12 hours ago.<br>Replaying the WAL<br>We now must catch up each shard's old backup to match the present state of the database. This requires replaying all changes from the Postgres Write-Ahead Log between 12 hours ago and now.<br>A naïve approach would be to pull the WAL directly from the primary. This is problematic for several reasons:<br>This would have nontrivial production impact. Replaying 12 hours of WAL on a high-churn database could take tens of minutes, or even an hour+.<br>Because we don't want too much server storage consumed by WAL, we continuously archive it to S3....