Database encryption is a mandatory control across virtually every regulated industry framework. HIPAA section 164.312(a)(2)(iv) requires encryption and decryption capabilities. PCI DSS Requirement 3 requires protection of stored cardholder data. NIST SP 800-111 guides storage encryption for federal systems under FedRAMP. GDPR Article 32 requires appropriate technical measures including encryption as a standard element of data protection. Meeting these requirements is not architecturally difficult. Meeting them without incurring unacceptable performance penalties requires understanding the specific performance characteristics of each encryption approach and selecting the architecture that places the cost where the system can absorb it.
Transparent Data Encryption: The Low-Cost Baseline
Transparent Data Encryption operates at the storage engine layer, encrypting database files, log files, and backups on disk without any modification to application queries or application code. SQL Server TDE, Oracle TDE, and MySQL InnoDB encryption all implement this pattern. PostgreSQL delegates to file-system-level encryption or cloud provider storage encryption rather than implementing TDE natively. The performance impact is modest, typically 3 to 8 percent CPU overhead for encryption and decryption of I/O operations, with no impact on in-memory query processing.
TDE's compliance limitation is significant: it protects against physical media theft and storage-layer access but does not protect against a database administrator with operating system credentials reading the database files while the service is running. The encryption key used by TDE is typically managed by the database service itself, accessible to anyone with database administrator privileges. For regulated workloads where insider threat is a concern, TDE satisfies encryption-at-rest requirements but does not satisfy the principle of least privilege for privileged database users. The HIPAA risk analysis must explicitly address this residual risk when TDE is the sole encryption control.
Column-Level Encryption: Higher Cost, Stronger Guarantees
Column-level encryption encrypts specific sensitive fields at the application or database layer before storage, using keys that the database service itself does not hold. PostgreSQL's pgcrypto extension, Oracle's column-level encryption, and application-layer encryption using libraries like libsodium implement this pattern. The encryption key is managed outside the database in a dedicated KMS so that even a database administrator with full table access cannot decrypt sensitive field values without separate KMS authorisation.
The performance tradeoff is material. Encrypted columns cannot be indexed for fast equality lookups. A WHERE clause on an encrypted field requires either decrypting all rows or using a deterministic encryption mode that reveals value equality. Deterministic encryption enables indexed lookups but leaks frequency information; randomised encryption is more secure but requires full decryption for search. For high-cardinality PHI fields like date of birth or Social Security Number that are used in patient matching queries, the query performance impact of column-level encryption can be severe without careful query rewriting and search index design.
In-Transit Encryption: TLS Configuration Details That Matter
TLS for database connections is universally supported. The compliance failure mode is not missing TLS support but misconfigured TLS enforcement: a database that accepts unencrypted connections when the client requests them because TLS is configured as optional rather than required. HIPAA section 164.312(e)(2)(ii) requires encryption for ePHI transmitted over open networks. An application that connects to its database over a private VPC network with TLS optional may be compliant by network isolation but fails the encryption requirement if the connection is unencrypted.
TLS version and cipher suite configuration matters for FedRAMP and DoD workloads. NIST SP 800-52 Rev 2 requires TLS 1.2 minimum, with TLS 1.3 recommended. Cipher suites must exclude 3DES, RC4, and export-grade ciphers. Database server TLS configuration should explicitly restrict the minimum TLS version and permitted cipher suites, not rely on default configurations that may accept legacy protocols for backwards compatibility.
Customer-Managed Keys and the HSM Integration
Customer-managed key encryption adds a layer of key custody control above cloud provider managed encryption. AWS KMS CMK, Azure Key Vault, and GCP Cloud KMS allow the organisation to own the encryption keys used to protect data in cloud-managed databases. The compliance benefit is key custody audit trails: every use of the CMK to encrypt or decrypt data generates a KMS API call that is logged, creating an immutable record of every decryption event. For regulated databases where the key access log is itself compliance evidence, CMK encryption delivers both the encryption control and the audit trail in a single implementation.
Hardware Security Modules provide the highest assurance key protection: keys generated in and never extractable from FIPS 140-2 Level 3 hardware. AWS CloudHSM, Azure Dedicated HSM, and GCP Cloud HSM implement this for cloud workloads. The operational complexity of HSM integration is substantially higher than software KMS. For FedRAMP High and DoD workloads where FIPS 140-2 Level 3 key protection is required, HSM integration is non-negotiable. For most HIPAA and PCI DSS workloads, software KMS with CMK achieves the required compliance posture at lower operational cost.
Encryption Architecture Decision Framework
The encryption architecture for a regulated database system should be selected by answering four questions in sequence. First, what is the threat model: are insider privilege abuse and cloud provider compromise in scope? If yes, TDE alone is insufficient. Second, what are the query patterns against sensitive fields: are encrypted fields used as search predicates or only retrieved? If searched, column-level encryption requires query pattern redesign. Third, what are the key custody requirements: does the regulation require customer-managed keys or HSM-grade key protection? Fourth, what is the performance budget: what query latency increase is acceptable? This last question determines whether column-level encryption is architecturally viable or whether a combination of TDE, CMK, and network isolation better balances security and performance for the specific workload.
EU AI Act: What CTOs Actually Need to Do Before August 2026
The Vendor Rescue Pattern: How to Recover a Failed Implementation in 12 Weeks
The LLM Hallucination Problem in Regulated Environments: What 'Acceptable Error Rate' Actually Means
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.