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 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 the full audit log. They don't need three years of telemetry partitions. They don't need the binary blob column carrying a million scanned PDFs.

What they do need is:

• 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 the feature under development — usually scripted post-clone.

Everything else — the millions of rows of personally identifiable information, the bulk historical data, the encrypted PDFs — is not just unnecessary. It is actively harmful: it slows the clone, balloons the storage bill, and (most damaging of all) drags production-grade PII into environments that don't deserve to hold it.

The 70 MB number isn't a typo

When you strip a clone down to only what developers actually need, the result is small. Surprisingly small. Across the workloads we see at DataTamed, a typical SQL Server clone lands somewhere between 60 and 70 megabytes. Not gigabytes. Megabytes.

That isn't because we're hiding anything. The schema is intact. The relationships are intact. Reference data is intact. The clone is fully usable as a SQL Server database — you can run your unit tests, your integration tests, your manual QA. What's missing is the bulk row data that nobody was reading anyway.

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 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.

Try the math on your own estate. 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 per year your team would reclaim by switching to second-scale cloning.

Or jump straight to a 14-day free trial and run a real clone on a real database. The first one will be done before you finish reading this paragraph.

← Back to all articles