Privacy and sanitization
How Local Snapshot detects and transforms sensitive PostgreSQL values before writing them locally.
Local Snapshot is designed to avoid persisting the selected production subset locally as-is.
Before Run, QueryDeck builds a privacy profile for the included columns.
Automatically protected fields
QueryDeck detects common sensitive data such as:
- email addresses;
- person names;
- phone numbers;
- postal addresses;
- IP addresses;
- birth dates;
- credentials, secrets, API keys, tokens, and similar fields.
Credential fields are protected and cannot be marked Keep original from the Local Snapshot UI.
Ambiguous data requires review
JSON and free-form text can contain anything. QueryDeck does not guess that those values are safe.
When a value needs a decision, choose one of the available actions such as:
- Redact
- NULL when the column allows it
- Keep original when you explicitly decide the value is acceptable for this local reproduction
The workflow cannot Run while required privacy decisions remain unresolved.
Relationships stay valid
Sanitization is deterministic where relationship consistency requires it.
If a sensitive value participates in a foreign key, both sides receive a compatible transformation so the local snapshot does not break the relationship simply because the value was de-identified.
Generated values also respect PostgreSQL type constraints such as bounded varchar, UUID, numeric, date/time, inet, arrays, and domains.
No cloud AI for row values
Local Snapshot does not send source row values to arbitrary cloud or third-party AI services.
Raw values necessarily pass through QueryDeck process memory and the database connection while being read and transformed, but QueryDeck does not intentionally persist an unsanitized intermediate dump.
What QueryDeck does not claim
Sanitized data is not automatically a legal guarantee of anonymity.
QueryDeck deliberately uses terms such as sanitize and de-identify rather than claiming GDPR compliance or irreversible anonymization.