Field-Level Encryption
also called Application-Level Encryption
Encrypting specific sensitive fields in the application before they reach the datastore, so the store never holds plaintext.
Storage-layer encryption protects against someone obtaining the disk or a raw snapshot. It does nothing against a compromised application, a stolen credential, or a database administrator — because the storage layer decrypts transparently for any authorised caller.
Field-level encryption raises the bar: the data is encrypted before it reaches the store, so database compromise yields ciphertext. It is the appropriate control for the highest-sensitivity fields — national identifiers, health data, payment details, credentials.
The cost is functional and it is significant. An encrypted field cannot be indexed, searched, sorted or range-queried in the ordinary way. Which is a design constraint rather than a setting, and it usually forces one of: exact-match lookup via a deterministic scheme (which leaks equality), a separate searchable token, or accepting that the field is retrieve-only.
Related techniques with different trade-offs: deterministic encryption enables equality joins and leaks which rows share a value; searchable encryption and blind indexing allow limited querying with careful trade-offs; and tokenisation replaces the value entirely, which is often the better answer because it removes the field from scope rather than protecting it.
Choose the fields deliberately. Encrypting everything makes the application unusable; encrypting nothing leaves the crown jewels behind one credential.