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: