What protection forbids

You cannot have confidentiality against a party who holds the key, and the key must be online wherever the data is used. So there is no configuration in which data is protected from its own legitimate processing path.
You cannot compress ciphertext, so encryption and the storage layer's efficiency machinery are directly opposed; and compressing a secret alongside attacker-controlled input leaks it through length.
You cannot encrypt a column and keep pruning, statistics or pushdown on it unless you preserve a relation. Any relation you preserve is recoverable by an adversary who has auxiliary data (outside knowledge about the population).
You cannot have both recoverable keys and provable crypto-shredding.
You cannot mask a column that remains filterable.
You cannot anonymize with any deterministic transform, at any strength.

Escapes and their prices

Escape	Buys	Pays
Full-disk encryption	disposal and media-loss safety, cheaply	nothing against any adversary arriving through the OS
Per-column encryption	protection from the platform operator	compression, pruning, statistics and pushdown on that column
Envelope encryption	line-rate bulk crypto with a hardened key boundary	key service becomes the real access-control point and a hot dependency
Property-preserving encryption	queryability on encrypted data	frequency or order analysis recovers much of the column
Crypto-shredding	O(1) deletion reaching copies you cannot enumerate	per-subject keys, lost compression, key loss = data loss, legally contested
Static masking	safe non-production copies	divergent second dataset; silent failure on new columns
Dynamic masking	single source of truth	query-plan cost, and leakage through predicates unless operators are restricted
Tokenization	auditable, rate-limited, revocable reversal	hot-path vault, total compromise on breach, still personal data
Salted hashing	cheap, no vault	per-record salt kills joins; global salt is a key with none of a key's benefits

Case, resolvedConstructed case · Wei at Hollis Health

An encrypted column, a 40-minute query

Encrypting national_id made queries take 40 minutes instead of 2, a vendor demo's hashed phone numbers were recovered in minutes, and a masked column still answered WHERE national_id = guesses. Where it started: Protection →

The 40-minute query. Wei stops encrypting the whole column for every purpose. She keeps national_id encrypted with a per-column key, so the platform operator cannot read it. She removes the column from filter and join paths: analysts use a separate non-sensitive patient_key (a surrogate, meaning an arbitrary number with no meaning) for joins, so statistics and pruning stay on the columns that queries actually use. She accepts that queries needing the real national_id are slow, and she puts them behind a request path.

The "anonymous" phone numbers. She tells Joon that a hash of a 10-digit number is reversible in seconds, and she replaces it with a vault token for the vendor demo. The token has no link to the phone number, but it is still a stable pseudonym, so she records the demo data as personal data in legal scope, not as anonymous. She also writes the adversary next to the control in her table: "tokenization: protects against a vendor who steals the demo file; does not protect against someone who gets vault access."

The WHERE national_id = ... trick. She changes the dashboard policy so the masked column cannot be used in WHERE, JOIN or GROUP BY, and she adds a test that tries exactly Mateus's query and must fail.

She also adds a row to the table for the key service itself: "who may call unwrap?" It is now the narrowest waist of the whole Lake.