Encryption at rest, and the question "against whom"

"Our data is encrypted at rest" is an answer to an audit question, and it usually does not answer the real one: who does that encryption stop?

Three layers, each stopping exactly one threat:

The most important and most misread point: disk encryption and TDE are transparent to every query. The database decrypts on read, so a SELECT * FROM users returns plaintext — whether that query is yours or an attacker's arriving through SQL injection. Those two layers stop losing the device, not losing access.

Which means if the threat you are worried about is "an application bug leaks card numbers", disk encryption contributes nothing, and only application-level encryption contributes.

But application-level encryption has three genuine costs, and they are why you should not encrypt everything:

• You cannot search it. WHERE email = @x does not work on an encrypted column. To search you must store an additional HMAC column of the value (not a plain hash, since a keyless hash is dictionary-attackable) for exact matching. Partial matching is not possible.
• You cannot sort or range-compare. An encrypted salary column cannot be ORDER BY-ed.
• Key management becomes your problem. And that is a harder problem than the encryption.

So the practical question is not "is it encrypted" but "which columns, against whom, and what are we giving up".