The 70 MB Manifesto

28 April 2026 8 min read #70MBClones

A 500 GB production database does not deserve a 500 GB test clone. Here's why the industry got SQL Server cloning wrong — and what a sane default looks like.

The default is broken

Open any DBA Slack on a Monday morning and you'll find the same conversation. A developer needs a fresh database for a feature branch. The "fresh" copy is going to be 50, 200, 800 gigabytes. The DBA queues up a RESTORE FROM DISK. It runs through coffee, through stand-up, through lunch. By the time the developer is unblocked, half a sprint day is gone.

This isn't an edge case. It's the default. And the default is genuinely broken — not because anyone made bad choices, but because the assumptions baked into "clone a database" predate the way modern engineering teams work.

A 500 GB production database does not deserve a 500 GB test clone. Click to share

Why production-sized clones are mostly waste

Here's the thing nobody quite admits in production planning meetings: your developers don't need 487 million rows of customer history to test the new "forgot password" flow. They don't need three years of telemetry partitions. They don't need the audit log going back to 2017. They definitely don't need the BLOB column carrying a million scanned PDFs of expense receipts.

What they actually need is a much shorter list:

• The full schema — every table, view, function, stored procedure, trigger, and constraint, exactly as in production.
• A representative dataset — enough rows to exercise joins, indexes, query plans, and edge cases.
• Reference data and lookup tables — countries, currencies, status codes, role definitions.
• Seed data for whatever feature is under development — usually scripted in post-clone.

Everything beyond that — the millions of rows of personal data, the historical bulk, the encrypted PDFs — isn't just unnecessary. It's actively working against you. It slows the clone, balloons the storage bill, and (worst of all) drags production-grade PII into environments that have no business holding it.

The 70 MB number isn't a typo

When you strip a clone down to only what developers actually need, the result is genuinely surprising the first time you see it. Across the SQL Server estates we see day-to-day at DataTamed, a typical clone lands somewhere between 60 and 70 megabytes. Not gigabytes. Megabytes. People usually re-check the number, then re-check it again.

And no — we're not hiding anything to get there. Schema: intact. Relationships and constraints: intact. Reference and lookup data: intact. It's a fully working SQL Server database — you can point your unit tests, your integration suite, your manual QA at it without changing a line. What's missing is exactly the stuff nobody was reading: the bulk row data.

And once the clone is 70 MB instead of 500 GB, three things happen:

1. Provisioning collapses from minutes to seconds. Nobody is waiting on disk I/O for a 70 MB file.
2. Storage costs collapse. Twenty environments × 70 MB is 1.4 GB. Twenty environments × 500 GB is 10 TB.
3. The PII problem largely solves itself. The vast bulk of personal data lives in the bulk row data we just stripped out.

Once a SQL Server clone is 70 MB instead of 500 GB, the PII problem largely solves itself. Click to share

What "still has PII" gets masked anyway

The reference data and the representative sample still contain some personal information — names attached to test users, sample emails, sample phone numbers. So we mask those too, automatically, at import time. Before the database image is ever stored. Before the first clone is ever spun up.

Six PII categories are detected automatically: names, emails, phone numbers, postal addresses, IP addresses, and dates of birth. Each is masked using a strategy you choose: partial masking (preserves format), redaction (replaces the value), or nullification (sets the column to NULL). Every action is logged in an exportable masking report — Word, Excel, PDF, CSV — for the auditor.

The four lies the industry tells about cloning

Lie #1: "You need full production data to find production bugs."

If a bug only reproduces with 487 million rows, the bug is a query plan issue and you can reproduce it in a load test against a stat-only clone. For 99% of feature work, a representative sample is not just sufficient — it's preferable, because it runs faster.

Lie #2: "Storage is cheap."

Storage is cheap until you multiply it by 20 environments × 100 developers × full-size clones × all the snapshots your DR plan retains. Then it isn't.

Lie #3: "We mask production data after restore."

Post-restore masking means production-grade PII did reach a non-production environment, even if it was overwritten an hour later. Your DPO is not impressed. Mask at import time, before the image is ever stored.

Lie #4: "Self-service cloning is risky."

Manual restore-and-mask scripts are the risk. They drift. They get skipped in a hurry. They produce inconsistent results across environments. A self-service flow with masking enforced at the platform level is dramatically safer than a checklist taped to the wall.

The 70 MB call to action

If your team is still waiting hours for a SQL Server clone, you're quietly paying three taxes you don't need to pay: the speed tax, the storage tax, and the compliance tax. None of them are necessary. None of them are inherent to SQL Server. They're just leftovers from a workflow nobody got round to redesigning.

Try the math on your own estate first. We built a free clone-time calculator that turns "how many databases × how often × how slow" into a single shareable number: how many engineering days a year your team would actually reclaim by switching to second-scale cloning.

Or skip the maths and jump to a 14-day free trial — point it at a real backup and run a real clone. The first one will be finished before you reach the end of this paragraph.

← Back to all articles