RE: Enquiry about TDE with PgSQL

Again, speaking for myself only and not officially for Quest.

" Uh, people will say that if the solution is not 100% secure in its coverage, it is much less useful and therefore not worth it."

I would assert that NO system is "100% secure" given enough money and resources. I think the more important point of this discussion is how users of PostgreSQL can "check the box" for compliance with whatever security and encryption "standards" are "required" in their environment, and/or mitigate the risks of not being "compliant".

Clay Jackson

-----Original Message-----
From: Bruce Momjian <bruce(at)momjian(dot)us>
Sent: Monday, November 3, 2025 6:06 PM
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: Kai Wagner <kai(dot)wagner(at)percona(dot)com>; Chris Travers <chris(dot)travers(at)gmail(dot)com>; Christophe Pettus <xof(at)thebuild(dot)com>; Clay Jackson (cjackson) <Clay(dot)Jackson(at)quest(dot)com>; pgsql-general <pgsql-general(at)postgresql(dot)org>; Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
Subject: Re: Enquiry about TDE with PgSQL

CAUTION: This email originated from outside of the organization. Do not follow guidance, click links, or open attachments unless you recognize the sender and know the content is safe.

On Mon, Nov 3, 2025 at 07:42:06PM +0100, Laurenz Albe wrote:
> On Mon, 2025-11-03 at 11:56 -0500, Bruce Momjian wrote:
> > The problem with the Percona extension is it seems like it was
> > developed mostly/all by Percona employees, meaning development was
> > driven/steered by Percona, and there was insufficient feedback from
> > the community for it to be polished enough to be a general community solution.
>
> Reading a Percona blog, it looks like you need a modified server to
> get to encrypt WAL, and they probably have no support for encrypting
> temporary files. So I'd say that TDE can probably not be a pure extension.
> Perhaps somebody from Percona can confirm.

Yes, the server has to be modified because the hooks they need don't exist in the community source code. They also have encryption control on the table level, which I frankly think will never work long-term because the storage API doesn't have enough table-level detail, so I think they are considering tablespace-level or cluster-level encryption.

> But I don't think it's a shortage of implementations for TDE that is
> the problem.
>
> Since you say that encrypting the temp files is the biggest hurdle for
> community acceptance, what about a first version that does not encrypt
> temp files? For one, that will be good for encrypted backups (which
> is one of the good use cases for TDE), and then you could argue that
> temp files are not data *at rest*, so data-at-rest-encryption does not
> apply to them. Rome wasn't built in a day, and neither were parallel
> query or declarative partitioning.

Uh, people will say that if the solution is not 100% secure in its coverage, it is much less useful and therefore not worth it.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us/
EDB https://enterprisedb.com/

Do not let urgent matters crowd out time for investment in the future.