Database encryption is the use of cryptography to make database data unreadable to anyone who lacks the correct keys, whether the data sits in files and backups or travels between clients and the server. In database security, it protects against threats that access controls alone cannot stop: stolen disks, copied backup files, intercepted network traffic and, in its stronger forms, administrators or attackers with direct access to the server.
Database encryption is not one feature but a set of layers. Encryption in transit protects connections, encryption at rest protects storage, and column-level or application-level encryption protects selected fields even from the database itself. Each layer defends against a different attacker, and all of them depend on sound key management.
Layers of database encryption
The layers differ mainly in where data is decrypted and who can therefore see plaintext. The deeper into the application the encryption happens, the fewer components can read the data, but the more database features stop working on it.
| Layer | Where plaintext exists | Protects against |
|---|---|---|
| Encryption in transit (TLS) | Client and server memory | Network eavesdropping and tampering |
| Storage or disk encryption | Everything above the disk layer | Stolen or discarded drives |
| Transparent data encryption (TDE) | Database server memory | Copied data files and backups |
| Column-level encryption in the database | Server during queries using the key | Readers without the column key |
| Application-level or client-side encryption | Application only | Database administrators and server compromise |
Transport Layer Security (TLS) should be enabled for every database connection, including connections inside a private network, with certificate verification turned on in the client. A client that encrypts but does not verify the server certificate remains open to man-in-the-middle attacks.
How transparent data encryption works
Transparent data encryption encrypts data pages and log files as the database engine writes them and decrypts them as it reads them into memory, so applications need no changes. SQL Server, Oracle Database and MySQL Enterprise offer TDE, MariaDB and MySQL encrypt InnoDB tablespaces, and PostgreSQL relies on file-system encryption or distribution-specific extensions.
TDE typically uses a two-level key hierarchy. A data encryption key (DEK) encrypts the data with a symmetric cipher such as AES-256, and a key encryption key (KEK), often called the master key, encrypts the DEK. The master key is kept outside the database in a keystore, a key management service or a hardware security module (HSM), which allows the master key to be rotated without re-encrypting every data page.
The protection TDE gives is real but narrow. Anyone who can query the running database sees plaintext, because the engine decrypts on behalf of every authorized session. TDE defends against theft of files and backups, not against SQL injection, stolen credentials or a malicious administrator.
Column-level and application-level encryption
When specific fields such as national identification numbers, card data or health records need stronger protection, they are encrypted individually. The choice of scheme determines which queries remain possible on the encrypted values.
| Scheme | Supports | Leaks |
|---|---|---|
| Randomized encryption | Storage and retrieval only | Nothing beyond length |
| Deterministic encryption | Equality lookups and joins | Which rows share the same value |
| Blind index with a keyed hash | Equality search on a separate column | Equality patterns |
| Order-preserving schemes | Range queries and sorting | Value order; generally considered weak |
| Secure enclave processing | Richer queries inside trusted hardware | Depends on enclave security |
Client-side encryption, such as Always Encrypted in SQL Server or the client-side field level encryption offered by MongoDB, keeps keys in the application tier so the database server never sees plaintext. The cost is lost functionality: encrypted columns cannot be searched with LIKE, aggregated or indexed for ranges without special techniques.
Key management and rotation
Encryption moves the security problem from the data to the keys, so key management decides whether encryption actually helps. Keys stored next to the data they protect, for example in the same backup or configuration file, provide almost no protection.
- Separate keys from data: keep master keys in a key management service or HSM, never in the database or its backups.
- Rotate keys on a schedule and immediately after suspected compromise; envelope encryption makes master key rotation cheap.
- Restrict and audit key access, and separate the duties of database administrators and key custodians.
- Plan key recovery: a lost master key makes every backup permanently unreadable.
Regulations and standards often require encryption of specific data. PCI DSS requires protecting stored cardholder data, and data protection laws such as the GDPR treat encryption as an appropriate technical measure that can reduce the consequences of a breach.
Database encryption compared with other security controls
Encryption complements the other database security controls but does not replace them. Each control answers a different question about who may see what.
| Control | Question it answers | Limitation |
|---|---|---|
| Database encryption | Can stolen files or traffic be read | Authorized sessions still see plaintext |
| Database role | Which objects may a user access | No protection for files outside the engine |
| Row-level security | Which rows may a user see | Relies on correct policies and identities |
| Database audit | Who did what and when | Detects misuse after the fact |
The usual performance overhead of TDE on modern processors with AES-NI hardware acceleration is modest, often reported in the low single-digit percent range, but it varies with workload and I/O pattern and should be measured before production rollout. Client-side encryption adds more overhead in the application and changes query design.
A non-technical view
Database encryption turns stored information into scrambled text that only someone with the right key can read. If a thief steals a hard drive or a backup copy, they get only meaningless characters.
There are several levels of protection. Some lock the whole storage room. Others lock individual drawers, such as the one holding card numbers. The most important rule is to keep the keys somewhere else. A locked box with the key taped to the lid protects nothing.
A concrete example
A healthcare clinic network stores patient records in a SQL Server database hosted in a shared data center. To meet its data protection obligations, the IT team enables TLS with certificate verification on all connections and transparent data encryption on the database, with the master key held in a hardware security module.
Diagnosis notes and national identification numbers receive client-side encryption, so the hosting provider’s administrators cannot read them even with full server access. Identification numbers use deterministic encryption so that reception staff can still look up a patient by exact number. When a backup tape later goes missing during transport, the team can show that it contained only encrypted data, and no patient information is exposed.