"Should I just encrypt everything in the database to be safe" is a question I get asked with some regularity, usually from someone who's read enough about encryption at rest to want to apply it broadly and stop thinking about it further. Worth walking through why that instinct, while understandable, usually isn't the right default.
What field-level encryption actually costs you
Encrypting a field at the application level, beyond whatever encryption your database provider already handles for you at rest, generally means that field can no longer be searched, sorted, or filtered directly by the database, since the database only sees scrambled, meaningless data. A field-level encrypted email address can't power a simple lookup query anymore without extra engineering to work around it. Encrypting everything by default tends to break exactly the features, search, filtering, sorting, that make a database useful in the first place, unless you build significant extra complexity to work around it for every single field.
Why 'encrypt everything' isn't actually the safe, lazy choice it sounds like
It sounds like the maximally cautious default. In practice, it's a significant engineering undertaking applied uniformly to data that mostly doesn't need it, while potentially distracting from the access-control work that actually prevents nearly every real incident I've written about. A perfectly encrypted field that a bad access rule still hands out to the wrong logged-in user, decrypted, because the application layer needed to decrypt it to function, gets you very little protection for a lot of engineering cost.
What's actually worth doing instead: deciding deliberately
- Government ID numbers, full payment card details if you're ever storing them directly rather than tokenizing through a processor, and similarly high-sensitivity fields are strong candidates for genuine field-level encryption.
- Names, emails, and most ordinary account information are usually better served by strong access control than by field-level encryption, since they need to remain searchable and usable for the app to function normally.
- Health information, depending on what you're building and where your users are, often has specific legal requirements worth understanding directly rather than guessing at.
- For nearly everything else, the access-control question, who can actually query this data, is doing more real protective work than encryption at the field level would.
The actual rule of thumb
Encryption at rest, handled by your database or hosting provider automatically, is worth having and usually already on by default with modern platforms, protecting against a stolen physical drive or storage breach. Field-level encryption on top of that is a deliberate, costly decision worth reserving for your genuinely highest-sensitivity fields, not a blanket default applied everywhere in the name of caution. Access control is nearly always the higher-leverage place to actually put your effort, and it's the thing that's caused nearly every real incident I've covered this year, not a lack of field-level encryption.