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.
  • Common contact fields, names, emails, phones, addresses, postcodes, dates of birth, matched by column name and replaced with realistic but fake values.
  • Same shape, same volume, same relationships, with far less real customer PII to secure in staging.
  • Not a substitute for checking your own schema, other identifiers and free-text notes are not matched automatically.

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 replaces the personal fields with fake values, 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 contact fields on the copy. Emails, names, phone numbers, addresses, postcodes and dates of birth become realistic but fake values, and the data still looks and behaves like production (same formats, same distributions, same foreign-key relationships), so your tests are meaningful and the contact details in your staging database belong to nobody.

Review the mask against your schema

Columns are matched by name, in your public schema, against a list of common contact-field names. Identifiers such as Medicare, TFN or member numbers, free-text notes, and PII stored in numeric columns are not matched automatically — and neither is a contact field whose column name we don't recognise. A masked clone is a large reduction in the personal information sitting in staging; it is not a guarantee that the copy is de-identified. Check the clone against your own schema, and treat it according to what it still contains.

Why not just anonymise it yourself?

Hand-rolled anonymisation scripts are easy to get wrong and easy to forget to run. 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.

It does not, however, remove the need to know your own schema. Ours matches columns by name, so a new PII column with an unfamiliar name is as invisible to us as it would be to your script — the difference is that the clone runs every time and your script might not. Keep a list of the columns in your schema that hold personal information, and check it against a clone whenever the schema changes.

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 matched contact fields anonymised, billed like any normal database. Point staging at the clone and your team tests against production-shaped data carrying far less real PII. (Deleting a masked clone is irreversible, so it's flagged before you confirm.)

The Australian-owned 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 Australian ownership in one step.