We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
This idea carries a full system design question on its own. Each walks through the full answer.
System Design Masterclass · Reliability Resilience
Free preview: the first 2 parts of this 6-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Reliability Resilience
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Your QA team needs to reproduce a bug that only appears when a table has 800 million rows. Staging has 2% of the data volume. A pg_dump of production would take 6 hours and lock tables the whole time. The developer guesses at the fix, ships it, and the bug is still there because the guess was wrong.
This is the problem database cloning solves. A clone is an exact copy of a production database that you can spin up in minutes, run destructive experiments against, and throw away when you are done. The production database never notices.
Aurora fast cloning, Neon branching, and storage-layer copy-on-write all use the same fundamental trick: the clone initially shares physical storage blocks with the source and only allocates new blocks when either side writes. For a 2 TB database, that means the clone is available in under 5 minutes and costs nearly nothing on day zero.
Shopify engineers wrote publicly in 2023 about cloning their 4 TB primary before every major schema migration. Notion does the same. Lyft clones production to validate query plans against real data distributions. The pattern is standard at any company running databases above 500 GB because the alternative, guessing whether a migration will work based on a fraction of the data, is how you get production incidents.
A clone is not a copy. At creation time, no data moves. The clone gets its own compute instance (a new database process with its own endpoint) that points at the exact same storage blocks as the source.
| Property | Clone (COW) | Traditional Copy (pg_dump) |
|---|---|---|
| Creation time (2 TB) | Under 5 minutes | 4 to 8 hours |
| Initial storage cost | Zero extra | Full duplicate |
| Impact on production | None | Table locks, I/O contention |
| Data freshness | Exact point-in-time snapshot | Exact point-in-time snapshot |
| Divergence over time | Blocks fork as either side writes | Independent from the start |
| Best for | Short-lived testing, migration rehearsal, forensics | Long-lived independent environments |
The copy-on-write mechanism works at the block level. When the clone reads a block that neither side has modified, it reads from the shared storage. When either the source or the clone writes to a block, the storage layer allocates a new block for the writer and preserves the original for the other side. This is transparent to the database process; it thinks it has its own private copy of every block.
The practical consequence is that clones are cheap when they are young and expensive when they are old. On day zero the overlap is 100% and the extra cost is just the compute instance. As blocks diverge through writes, vacuum, and index maintenance, the shared fraction shrinks and storage costs grow toward a full duplicate.