A safe MongoDB export removes sensitive values before they reach the output file. Filter the smallest useful population, preserve BSON types, pseudonymize fields that must remain joinable, redact fields whose value should disappear, and exclude fields the consumer does not need. Do all of that while streaming. A 20 GB JSON array is less a file format and more a hostage situation.
Start by reducing the population
Masking is not a substitute for selecting the right documents. Build the filter or read-only aggregation first:
db.orders.find(
{
status: "completed",
createdAt: { $gte: ISODate("2026-01-01T00:00:00Z") }
},
{
customerId: 1,
"customer.email": 1,
region: 1,
total: 1,
createdAt: 1
}
)
This projection omits fields the analytical consumer never requested. Fewer fields mean fewer masking rules and fewer ways to miss something.
MongoDB Compass can export a full collection, filtered query results, or aggregation results as JSON or CSV. Its import and export documentation also warns that CSV can lose type information and is not appropriate for backup. That is a format warning, not a privacy control. The values you selected are still the values that leave.
Redact, pseudonymize, and exclude solve different jobs
Use exclude when the receiving system does not need the field at all. Removing customer.phone, access tokens, free-text notes, and internal flags is cleaner than producing realistic-looking replacements nobody will use.
Use redact when consumers need the field to exist or retain its type, but not its identity. Every email can become one string placeholder; every date can become a type-compatible date. Equality disappears, which is often the safest result.
Use pseudonymize when equality carries analytical value. If the same customerId appears in an order, a refund, and a support event, equal inputs should map to equal outputs within that export. The original identifier should not be recoverable from the output alone.
Pseudonymized data is not automatically anonymous. Rare combinations, free text, timestamps, and location can still identify a person. Privacy work gets inconvenient precisely where it gets real.
Studio 3T's MongoDB data masking documentation validates the demand for field-level transforms, preview, and masking during export. Its broader tool can also write masked data to another collection or overwrite a source. mongoui deliberately narrows Privacy Export to the streamed copy, so the masking workflow cannot mutate production data.
Canonical Extended JSON preserves BSON distinctions
Ordinary JSON has strings and one broad number type. MongoDB has ObjectId, Date, Decimal128, Int32, Int64, Binary, Timestamp, Regex, and more. Flattening those values can make an exported fixture readable but semantically wrong.
Canonical Extended JSON represents the BSON category explicitly:
{
"_id": { "$oid": "64f000000000000000000001" },
"createdAt": { "$date": { "$numberLong": "1767225600000" } },
"total": { "$numberDecimal": "149.95" }
}
MongoDB's Extended JSON reference defines canonical and relaxed forms. Canonical output is noisier and better for fidelity. Relaxed output is easier on the eyes and easier to misread as lossless.
Newline-delimited JSON writes one complete document per line. A cursor can stream each document through the masking transform and onto disk without materializing the full result set. That is the practical format for large exports and line-oriented tools.
Pseudonyms need a clear scope
A deterministic pseudonym needs a secret key. The scope of that key decides where equal values remain equal.
A single export-scoped key has useful properties:
- repeated values remain joinable inside one file;
- two separate exports produce different pseudonyms;
- the key never needs to be saved next to the output;
- an old file cannot be casually joined to a later file by pseudonym.
That scope is safer than one permanent global key. It is less suitable when a team explicitly needs stable pseudonyms across scheduled exports. That requirement deserves managed key storage, rotation, access control, and a documented re-identification policy. It should not appear by accident because somebody cached a random seed in local storage.
Preview the transform, then inspect the output
Before a long export, preview the same transform against one already-visible document. Check nested dotted paths, arrays, missing fields, and mixed BSON types. A rule for customer.email does nothing to billing.email, which is both obvious and the reason privacy reviews involve checklists.
After export, sample the actual file:
- Search for known email, phone, token, and identifier patterns.
- Confirm excluded paths are absent.
- Confirm pseudonymized equality works where required.
- Parse canonical Extended JSON back into BSON-aware values.
- Confirm the file contains only the filtered population.
- Apply the receiving system's retention and access policy.
Do not call the export a backup. Data masking intentionally changes or removes values. Use MongoDB backup tooling for recovery and a masked export for controlled analytical or development use.
Privacy Export keeps the source untouched
In mongoui, run the reviewed find or aggregation, choose Privacy export, and add up to 50 dotted-path rules. Pseudonymize keeps equal values joinable within this file. Redact uses type-compatible constants. Exclude removes the field.
Preview uses the same privileged local masking engine as export. The export streams canonical NDJSON in batches through an atomic temporary file. Canceling closes the MongoDB cursor and removes the incomplete output. Source documents are never updated, and the fresh random pseudonymization key is never persisted.
The Privacy Export guide covers the exact controls. For ordinary query and snapshot workflows, see document and bulk updates. The broader feature overview explains how local exports, AI egress, and database writes use separate boundaries.
Mask early, validate the file, and give the recipient less data than they asked for. They can always ask for another field. They cannot un-receive the first export.