Database Encryption: At Rest, In Transit, In Use

Database encryption is table stakes; the layer specifics matter for both threat model and compliance.

Three encryption layers

Database encryption splits across three layers. Each protects a different threat surface; mixing them up leads to either over-engineering or false confidence.

• At rest. Data on disk encrypted; storage-engine layer; protects backup tapes, decommissioned drives, stolen instances.
• In transit. Data over the network encrypted; TLS 1.2+ between client and database; protects against on-path sniffing.
• In use. Data in memory encrypted; trusted execution environments (TEEs); rare, growing for regulated AI workloads.
• Compose, don’t substitute. Each layer covers a different attacker; production workloads need at-rest and in-transit by default.

Threat model per layer

Each encryption layer maps to a specific attacker and attack surface. Without naming the threat, the layer is decoration.

• At rest. Protects against stolen disk, leaked backup, decommissioned drive sold on eBay; the physical/storage threat.
• In transit. Protects against network sniffing, MitM, untrusted intermediate hops; the network threat.
• In use. Protects against compromised host, malicious cloud operator, side-channel attacks; the runtime threat.
• What encryption doesn’t protect. Compromised application credentials; SQL injection; over-permissive grants; encryption is not access control.

Performance cost

Encryption is not free, but the cost has shrunk every year. The real question is whether the workload notices, not whether overhead exists.

• At rest. 1-3% overhead with AES-NI hardware support; effectively zero with managed services like RDS or Cloud SQL.
• In transit. 5-15% overhead for the TLS handshake; near-zero for steady-state encrypted traffic; connection pooling matters.
• In use. Significant; SGX/TDX enclaves cap at small memory; only justified for the highest-stakes data.
• The diagnostic. Measure on your workload; defaults from a benchmark blog post will not match your shape.

Regulatory drivers

Encryption requirements come from compliance frameworks. Knowing which framework drives which layer prevents over- or under-shipping.

• SOC 2. At-rest and in-transit are table stakes; auditors flag missing TLS or unencrypted volumes immediately.
• HIPAA, PCI. Same as SOC 2 plus documented key management; rotation, escrow, separation of duties.
• EU AI Act. Growing emphasis on in-use encryption for ML training data; TEE deployment patterns becoming auditable.
• The shape. Map the regulation to the layer before procuring; encryption choices outlive the team that picks them.

Antipatterns

• Encryption without key rotation. Drift over years.
• Same key for everything. Compromise = total.
• In-use encryption when not required. Premature complexity.

What to do this week

Three moves. (1) Apply this pattern to your most-loaded table. (2) Measure query latency / write throughput before/after. (3) Document the win and the constraint so the next refactor inherits the knowledge.