Re: Enquiry about TDE with PgSQL

Just wanted to throw in my two cents, or actually, two points, on TDE:

1.

Extensions seem like the right place for most of the TDE logic.
Encryption usually depends on organization specific or even
proprietary security systems. Think of features like KMS integrations that
need custom handling and are often owned by Security, Compliance, or IT
rather than DBAs, so it is hard to convince DBAs to stick to a "supported"
one.
That kind of setup is difficult to generalize into PostgreSQL core, and
extensions give the flexibility to make it work. The same goes for cloud
KMS or HSM certification integrations, which add another layer of
complexity that is easier to manage outside core.
Also, by relying mainly on new hooks, we can keep changes to the core
minimal and make TDE as non-intrusive as possible for those who do not need
it.
2.

About the "single-vendor open source" comment...
That was never the goal when we kicked off pg_tde. Sure, Percona funded
the initial work, but we would really like to see this become a broader
community effort.
We saw a gap that enterprise users were facing and tried to fill
it based on what we had learned from other databases, but the more people
get involved, the better this can become.

On Tue, Nov 4, 2025 at 3:06 AM Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> 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://url.avanan.click/v2/r01/___https://momjian.us___.YXAzOnBlcmNvbmE6YTpnOjI1Nzk5MzJmMmQ0NDFlMGE0NGRhMjc4NDMwYWVkZDZlOjc6MTFhOToxZDRhZjAyODZkMjQ3MzlhM2EwMWUzNmFkZGM0ZTkyYmQ3MjE0NWVlY2VjZDRmYTFkMWM2NTUxOTUwYjQ1OGY5OnA6VDpO
> EDB
> https://url.avanan.click/v2/r01/___https://enterprisedb.com___.YXAzOnBlcmNvbmE6YTpnOjI1Nzk5MzJmMmQ0NDFlMGE0NGRhMjc4NDMwYWVkZDZlOjc6ZGM0YTphNjQ1MzQyOWEyNzBiNzYyYTc5NjJlN2NlYjU1ZTM5YmZkYWZjMTYyNzViN2IzNWQzOTU4N2QxZTIwNjcxMDdlOnA6VDpO
>
> Do not let urgent matters crowd out time for investment in the future.
>
>
>

--

<https://www.percona.com/>

Jan Wieremjewicz
Sr. Product Manager, Percona
jan(dot)wieremjewicz(at)percona(dot)com <email(at)percona(dot)com>

CET (GMT+1)

Databases Run Better With Percona