Protect a sensitive field
A column holds values that must not be read by everyone who reads the table: national IDs, phone numbers, salaries, diagnoses. Every protection keeps some structure of the original data so the data stays useful, and every property you preserve to keep it useful is a property you have published. Which structure does this field's use actually need?
You will end with the transformation for this field, the structure it keeps, and therefore what it still leaks and what it costs.
Decide
Must readers still join or count on this field?
Why
Any transformation that lets you link records across datasets has preserved identity, because linkage is what identity is in a data system. So a field that must still join can be pseudonymized, never anonymized.
Can readers ask arbitrary questions, or is this one fixed release?
Arbitrary questionsAggregate with noise
One fixed releaseGeneralize to groups of k
Why
An interface that answers arbitrary aggregates is a system of linear equations, and enough answers solve it: the total salary of everyone, minus the total of everyone except Rosa, is Rosa's salary. You cannot defend a release by inspecting the release.
Is the threat a person with legitimate access copying data out over time, rather than a stolen copy?
Why
Decryption is offline, unobservable and unstoppable once the key is out. Detokenization is a service call: it can be authorized per request, rate-limited, logged and revoked.
Where you can land
Mask a copy
Use it when readers need realistic records but not the value, as in development, test and vendor demos.
What it costs: a second dataset, with its own lineage, staleness, and a masking job that must follow every schema change. A new sensitive column nobody added to the masking configuration passes through unmasked and silently.
Before you build it
If you mask at read time instead, close the predicate
Masking the output does not mask the predicate. A user who can write WHERE national_id = … learns the value one guess at a time from the row count. Restrict the operators allowed on the column (equality, ranges, joins, grouping), not only its display.
Keyed hash: a stable pseudonym
Use it when records must still join on the field.
What it costs: key management, with none of encryption's reversibility. A plain hash protects nothing: a 10-digit phone number has 10¹⁰ values, about ten seconds of hashing at 10⁹ a second. A per-record salt defeats that and destroys the join; a global salt keeps the join and is, in effect, a key.
Generalize to groups of k
Use it when one release, read as rows.
What it costs: precision, by generalizing values (birth year instead of birth date) and suppressing rows that still stand alone, until every combination of quasi-identifiers appears at least k times. Identity is spread across the whole row, so removing names is not enough; and the guarantee looks only at the table, so it fails against a reader who knows more.
Aggregate with noise
Use it when readers may ask arbitrary aggregate questions.
What it costs: accuracy, and a budget. Noise scales with the query's sensitivity divided by ε, so counts over small groups become poor, and every answer spends part of a privacy budget that is finite and depletes.
Tokenize
Use it when real values must be recoverable, and recovery must be watched.
What it costs: a vault on the hot path of every workload that needs real values: an availability dependency and a scaling problem. In return, every reversal is an event you can log, throttle and revoke.
Encrypt the column
Use it when the threat is a stolen copy, and real values must be recoverable.
What it costs: the data becomes exactly as secret as the key, and the key must be available wherever the data is used. The unit of decryption must be at least the unit of access. An encrypted column loses dictionary encoding, run-length encoding, statistics and pruning: a query that read 40 GB of a 2 TB table now reads all 2 TB.
Before you build it
Compress first, and do not buy structure back
Ciphertext does not compress, so compress before encrypting, knowing that the ciphertext's length still reveals how compressible the plaintext was. Deterministic or order-preserving encryption keeps joins and ranges working, and leaks equality or order to anyone who holds the bytes.