GoKawiilBen Dicken [@ BenjDicken] | July 31, 2026
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.
Such backups are crucially important and simultaneously something that most engineers would rather never have to think about.
Just make the backup work.
Our goal at PlanetScale is to make taking, scheduling, managing, and restoring Postgres and MySQL backups effortless.
Though this is what our customers experience from the outside, achieving this internally requires careful orchestration of cloud infrastructure and DBMS tooling.
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.
Here we take a behind-the-curtain look at how to effectively back up a sharded database with massive parallelism.
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.
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).
... continue reading