Every team wants staging to behave like production, so the tempting shortcut is to clone the production database into it. The problem: that copy carries real people's names, emails, phone numbers and addresses into an environment with weaker access controls, more people poking at it, and often less monitoring. Under Australian privacy law, that copy is still personal information — and still your responsibility. Masked clones remove the risk while keeping the realism.
What a masked clone is
- A one-click copy of a Scale database into a brand-new database.
- Personal fields — names, emails, phones, addresses, dates of birth — replaced with realistic but fake values.
- Same shape, same volume, same relationships — safe to hand to staging or a contractor.
The hidden risk in your staging database
A production clone in staging is a quiet liability. It widens the blast radius of any breach, it's often reachable by people who'd never get production access, and it can end up in laptop backups, screenshots and support tickets. None of that is malicious — it's just what happens when real data goes somewhere it was never meant to live.
What Australian privacy law expects
Under the Privacy Act and the Australian Privacy Principles, personal information must be protected wherever it's held — and a test environment is no exception. De-identifying data before it leaves production is a recognised, practical way to reduce that obligation: if the copy contains no real personal information, there's far less to secure and far less to lose. The 2024 reforms raised the stakes on getting this right.
What a masked clone does
A masked clone copies a Scale database into a new one and rewrites the personal fields on the copy. Emails, names, phone numbers, addresses and dates of birth become realistic but fake values — the data still looks and behaves like production (same formats, same distributions, same foreign-key relationships), so your tests are meaningful, but none of it maps back to a real person.
Why not just anonymise it yourself?
Hand-rolled anonymisation scripts are easy to get wrong and easy to forget to run — one new PII column and your masking is silently incomplete. A built-in masked clone makes the safe path the easy path: it's one action in the console, it produces a clean, separate database, and there's no window where an unmasked copy exists in staging.
How to use it
Masked clones are available on the Scale tier. From the console, choose your Scale database and create a masked clone; WattleDB provisions a new database with the personal fields anonymised, billed like any normal database. Point staging at the clone and your team tests against production-shaped, privacy-safe data. (Deleting a masked clone is irreversible, so it's flagged before you confirm.)
The sovereign angle
Like everything on WattleDB, the clone stays in Australia on Australian-owned infrastructure — so de-identifying your test data doesn't come at the cost of sending it offshore to some masking SaaS. Realism, privacy and sovereignty in one step.