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 are meant to reduce the risk while keeping the realism.

What a masked clone is meant to be

  • A copy of a Scale database into a brand-new database.
  • Common contact fields (emails, phones, street addresses, postcodes, dates of birth, and any column whose name ends in _name) 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, free-text notes, large objects and text arrays 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 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.

How a masked clone works

A masked clone is meant to copy a Scale database into a new one and rewrite 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 matched contact fields in your staging database belong to nobody.

Review the mask against your schema

Columns are matched by name, in your public schema, against a published set of patterns: email, phone/mobile, address/street, postcode, the date-of-birth spellings, and any column ending in _name, minus a published exception list of technical, catalogue and locality names (product_name, table_name, status_name, city_name) that are left readable so the clone stays useful. Identifiers such as Medicare, TFN or member numbers, free-text notes, and PII stored in numeric or jsonb columns are not matched automatically, and neither is a contact field whose column name we don't recognise, such as username, initials, or a camelCase spelling like firstName. 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 only anonymise it yourself?

Hand-rolled anonymisation scripts are easy to get wrong and easy to forget to run. A built-in masked clone is meant to make the safe path the easy path: one action in the console that produces a clean, separate database, with the copy not visible until masking has finished.

It does not, however, remove the need to know your own schema. Ours matches columns by name. That is broad for names (anything ending in _name is replaced), but a PII column with a name we don't recognise (medicare_no, notes, dob_text, or a camelCase firstName) is as invisible to us as it would be to your script; the difference is that a clone would run 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.

Where it stands

Masked clones are paused, so you can't create one today. We believe no masked clone has been able to copy its data since 7 October 2026. From 16 October 2026 the console button is disabled and requests are refused with “Masked clones are temporarily unavailable while we fix how a clone copies its data.” Clones are not charged at present. We have not set a date for them to return. Until they do, anonymise a copy yourself before it leaves production. When they return, they are meant for the Scale tier: you choose a Scale database in the console and create a masked clone, and WattleDB provisions a new database with the matched contact fields anonymised.

The Australian-owned angle

Like everything on WattleDB, a clone would stay in Australia on Australian-owned infrastructure, so masking your test data would not mean sending it offshore to a masking service.