Database encryption gets treated as done once TLS is enabled on the connection and disk-level encryption is turned on at the infrastructure layer. Both are genuinely necessary and both leave a real gap: they protect data moving over the network and data on a stolen physical disk, but they do nothing if someone gains direct query access to your database - through a compromised application server, an over-privileged internal tool, or a leaked database credential. Row-level and field-level encryption closes exactly that gap, for the specific data where it actually matters.
Why “encryption at rest” alone isn’t sufficient
Disk-level (or “at rest”) encryption protects against a specific threat: someone physically stealing a hard drive or unauthorized access to the underlying storage. It does nothing to protect against the far more common real-world breach pattern - a compromised application server, an exposed database credential, or an internal tool with broader access than it should have, all of which give an attacker a live, decrypted view of the data through normal query access, because at-rest encryption is transparent to anything querying through the database engine itself.
What field-level encryption actually adds
Encrypting specific sensitive fields - account numbers, government ID numbers, health records, precise location data - at the application layer, before they’re ever written to the database, means that even someone with direct database query access sees ciphertext, not the actual sensitive value, unless they also have the specific decryption key, which should be managed and access-controlled entirely separately from the database itself. This is the layer that protects against the breach pattern that at-rest encryption doesn’t touch.
What this actually requires to implement well
- Deliberate scoping - encrypt what’s actually sensitive, not everything. Encrypting every field indiscriminately makes querying, indexing, and general database operations significantly harder for no additional security benefit on non-sensitive data. Identify the genuinely sensitive fields (PII, financial data, health data) and encrypt those specifically.
- Proper key management, separate from the data itself. Encryption keys should live in a dedicated secret management system (AWS KMS, HashiCorp Vault, or similar) with its own access controls and audit logging - not in application config files, not in the same database as the data they protect. If an attacker who compromises your database also has trivial access to the decryption keys, the encryption isn’t providing real protection.
- Key rotation as a genuine, tested process, not a theoretical capability - being able to actually rotate encryption keys periodically, and having a tested process for re-encrypting existing data when you do, rather than a rotation policy that exists on paper but has never actually been executed.
- Accepting the real trade-off in queryability. Encrypted fields generally can’t be efficiently searched, filtered, or indexed the way plaintext fields can - this is a genuine architectural trade-off, not just an implementation detail, and it needs to be designed around (searchable encryption schemes, or restructuring which fields need to be queryable versus which need to be maximally protected) rather than discovered after the fact when a feature needs to filter by an encrypted field.
Where we’ve seen this go wrong
Almost always one of two mistakes: encryption implemented so broadly that it cripples normal application performance and query flexibility, leading teams to eventually roll it back under pressure - or encryption keys stored in a way that’s only marginally more protected than the data itself, providing compliance-checkbox value without real security value. Getting the scope and key management right upfront avoids both.
What we actually recommend
Identify your genuinely sensitive fields specifically, encrypt those with a properly separated key management system, and design your data access patterns around the queryability trade-off from the start rather than retrofitting it later. This is standard practice on any backend system we build that handles sensitive personal or financial data.
If you’re handling sensitive data and aren’t confident your current protection would hold up against direct database access, not just a stolen disk, get in touch for an honest assessment.