I'm a huge fan of MSSQL's transparent data encryption in situations where we have more than 1 client per database engine, and we want to separate the data physically.
I worked on a project where separate databases (a la Postgres) tied to separate clients wasn't enough. Postgres still can read across the databases.
With TDE we tie the key to the individual clients meaning even if the engine messes up, since the connection isn't made with the right key, you still can't read the contents.
We still did encryption at rest as that comes for free these days, for reasons mentioned here in the comments.
I just wish Postgres would come with TDE. Paying for software is fine, but the cost of MSSQL is way more than $0. In fact, it's usually cheaper to set up a Postgres instance per client. That way, when the engine messes up, well, there is only data of that client.
And I know a database is unlikely to mess up. I'm more likely the culprit, and as such I prefer to have my guardrails.
I worked on a project where separate databases (a la Postgres) tied to separate clients wasn't enough. Postgres still can read across the databases.
With TDE we tie the key to the individual clients meaning even if the engine messes up, since the connection isn't made with the right key, you still can't read the contents.
We still did encryption at rest as that comes for free these days, for reasons mentioned here in the comments.
I just wish Postgres would come with TDE. Paying for software is fine, but the cost of MSSQL is way more than $0. In fact, it's usually cheaper to set up a Postgres instance per client. That way, when the engine messes up, well, there is only data of that client.
And I know a database is unlikely to mess up. I'm more likely the culprit, and as such I prefer to have my guardrails.