Re: Enquiry about TDE with PgSQL - Mailing list pgsql-general

From Bruce Momjian
Subject Re: Enquiry about TDE with PgSQL
Date
Msg-id aQYSAGEfd116_58N@momjian.us
Whole thread Raw
In response to Re: Enquiry about TDE with PgSQL  (Kai Wagner <kai.wagner@percona.com>)
Responses Re: Enquiry about TDE with PgSQL
Re: Enquiry about TDE with PgSQL
List pgsql-general
On Sat, Nov  1, 2025 at 08:34:57AM +0100, Kai Wagner wrote:
> I wholeheartedly agree, as in this thread we are trying to do the same thing
> again, that has already happened all they years before. We lose ourselves in
> technical reasons, wondering why this makes no sense and how it could be
> achieved differently, but we forget that we live in a vacuum and bubble here. 
> The auditor, most of the time (as I've seen many times), has no knowledge of
> these technical aspects. It's a box to check, with a simple 'yes' or 'no'. They
> don't even wanna hear any "but this also satisfies it, as this isn't clearly
> stated and worded in the standard". This doesn't get us anywhere anymore; they
> will not put their checkbox there if there is no simple answer to it.
> 
> @Bruce Momjian I totally understand your frustration from previous times and
> also your point of view, that's absolutely valid, no doubt about that. The time
> has changed over the course of the last 5+ years, and maybe it is time to
> reconsider. Just because it didn't succeed last time doesn't mean we have to
> end up in the same spot this time. We discussed it at length, and I am
> committed to supporting and making happen what's necessary to get TDE fully
> functional with postgres directly. The way of the implementation is a different
> question. Who from the former times, or maybe even now, being interested in the
> topic, would be open for a TDE group, to technically discuss options,
> possibilities etc. that we can POC on and share for further feedback?!

Without the calculus of feature value vs code overhead changing, talking
isn't going to accomplish anything.  My patch was already very small for
shared buffers, and the WAL code would have been small, but the code
weight of encrypting temporary files wasn't justified by the community,
and I couldn't argue against that conclusion.

Crunchy had someone working on restructuring temporary file writes to
make it easier, but they were unsuccessful.  Maybe the posted temporary
file compression patch will help reduce the code weight.

If you want to move forward with TDE without waiting to see if the
temporary file compression patch will reduce the TDE code impact, you
need to dig into how the community does feature calculus and how that
calculus can be changed --- this is not something technology can fix.

Companies are willing to add the code weight because it is a sale for
them, and customers are willing to pay to meet the check box --- that
calculus just doesn't work in the community.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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



pgsql-general by date:

Previous
From: Kai Wagner
Date:
Subject: Re: Enquiry about TDE with PgSQL
Next
From: Adrian Klaver
Date:
Subject: Re: Enquiry about TDE with PgSQL