public inbox for [email protected]
help / color / mirror / Atom feedRe: Enquiry about TDE with PgSQL
36+ messages / 11 participants
[nested] [flat]
* Re: Enquiry about TDE with PgSQL
@ 2025-10-16 22:04 Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
0 siblings, 1 reply; 36+ messages in thread
From: Greg Sabino Mullane @ 2025-10-16 22:04 UTC (permalink / raw)
To: Ashish Mukherjee <[email protected]>; +Cc: pgsql-general
>
> I would like to enquire that based on the anecdotal experience of group
> members, which TDE solution works best for PgSQL 17 databases.
Generally speaking, there is no "best". People use whatever vendor they
happen to already use. Your best solution is to avoid TDE altogether. If
you really need encryption at rest, have the OS do it. That works well
(transparently, even), is very battle-tested, and has minimal performance
impact. TDE, on the other hand, is a very complex and difficult thing to
add into Postgres. Currently it means you are using a forked version of
Postgres and are incurring overhead every time you read or write to disk.
The scenario I have is of a large number of tables (15-20K) and some
> tables with 100M tuples each. The total database size is 4TB.
The size and number of tables does not really matter. How often you write
WAL, and how often things move in and out of shared buffers is what matters.
Cheers,
Greg
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
@ 2025-10-17 04:49 ` Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
0 siblings, 1 reply; 36+ messages in thread
From: Ron Johnson @ 2025-10-17 04:49 UTC (permalink / raw)
To: pgsql-general
On Thu, Oct 16, 2025 at 6:05 PM Greg Sabino Mullane <[email protected]>
wrote:
> I would like to enquire that based on the anecdotal experience of group
>> members, which TDE solution works best for PgSQL 17 databases.
>
>
> Generally speaking, there is no "best". People use whatever vendor they
> happen to already use. Your best solution is to avoid TDE altogether. If
> you really need encryption at rest, have the OS do it. That works well
> (transparently, even), is very battle-tested, and has minimal performance
> impact.
>
But filesystem encryption still means that validly logged-in users see the
unencrypted data. That's great for a laptop that might get stolen, or for
drives that are discarded without being wiped, but are no protection
against hackers who want to exfiltrate your data.
(Neither protect against ransomware, but that's a different problem.)
> TDE, on the other hand, is a very complex and difficult thing to add
> into Postgres.
>
TDE was added to SQL Server, with (to us, at least) minimally-noticed
overhead. Oracle has it, too, but I don't know the details.
The bottom line is that requirements for TDE are escalating, whether you
like it or not, as Yet Another Layer Of Defense against hackers
exfiltrating data, and then threatening to leak it to the public.
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
@ 2025-10-17 07:01 ` Laurenz Albe <[email protected]>
2025-10-17 12:47 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
0 siblings, 2 replies; 36+ messages in thread
From: Laurenz Albe @ 2025-10-17 07:01 UTC (permalink / raw)
To: Ron Johnson <[email protected]>; pgsql-general
On Fri, 2025-10-17 at 00:49 -0400, Ron Johnson wrote:
> On Thu, Oct 16, 2025 at 6:05 PM Greg Sabino Mullane <[email protected]> wrote:
> >
> > TDE, on the other hand, is a very complex and difficult thing to add into Postgres.
>
> TDE was added to SQL Server, with (to us, at least) minimally-noticed overhead.
> Oracle has it, too, but I don't know the details.
>
> The bottom line is that requirements for TDE are escalating, whether you like it or
> not, as Yet Another Layer Of Defense against hackers exfiltrating data, and then
> threatening to leak it to the public.
Bruce Momjian has interesting things to say about that in
https://compiledconversations.com/6/ (unfortunately I don't remember where
exactly in this 84 minute piece).
It is a feature that users want (or need to comply with whatever they feel
they have to comply with). On the other hand, it has very limited technical
or security value, which hampers its acceptance into core.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
@ 2025-10-17 12:47 ` Ron Johnson <[email protected]>
1 sibling, 0 replies; 36+ messages in thread
From: Ron Johnson @ 2025-10-17 12:47 UTC (permalink / raw)
To: pgsql-general
On Fri, Oct 17, 2025 at 3:01 AM Laurenz Albe <[email protected]>
wrote:
> On Fri, 2025-10-17 at 00:49 -0400, Ron Johnson wrote:
> > On Thu, Oct 16, 2025 at 6:05 PM Greg Sabino Mullane <[email protected]>
> wrote:
> > >
> > > TDE, on the other hand, is a very complex and difficult thing to add
> into Postgres.
> >
> > TDE was added to SQL Server, with (to us, at least) minimally-noticed
> overhead.
> > Oracle has it, too, but I don't know the details.
> >
> > The bottom line is that requirements for TDE are escalating, whether you
> like it or
> > not, as Yet Another Layer Of Defense against hackers exfiltrating data,
> and then
> > threatening to leak it to the public.
>
> Bruce Momjian has interesting things to say about that in
> https://compiledconversations.com/6/ (unfortunately I don't remember where
> exactly in this 84 minute piece).
>
> It is a feature that users want (or need to comply with whatever they feel
> they have to comply with). On the other hand, it has very limited
> technical
> or security value, which hampers its acceptance into core.
>
I gave you a reason: "Yet Another Layer Of Defense against hackers
exfiltrating data". It's the same reason PgBackRest encrypts backups.
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
@ 2025-10-30 19:59 ` Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
1 sibling, 1 reply; 36+ messages in thread
From: Bruce Momjian @ 2025-10-30 19:59 UTC (permalink / raw)
To: Laurenz Albe <[email protected]>; +Cc: Ron Johnson <[email protected]>; pgsql-general
On Fri, Oct 17, 2025 at 09:01:52AM +0200, Laurenz Albe wrote:
> On Fri, 2025-10-17 at 00:49 -0400, Ron Johnson wrote:
> > On Thu, Oct 16, 2025 at 6:05 PM Greg Sabino Mullane <[email protected]> wrote:
> > >
> > > TDE, on the other hand, is a very complex and difficult thing to add into Postgres.
> >
> > TDE was added to SQL Server, with (to us, at least) minimally-noticed overhead.
> > Oracle has it, too, but I don't know the details.
> >
> > The bottom line is that requirements for TDE are escalating, whether you like it or
> > not, as Yet Another Layer Of Defense against hackers exfiltrating data, and then
> > threatening to leak it to the public.
>
> Bruce Momjian has interesting things to say about that in
> https://compiledconversations.com/6/ (unfortunately I don't remember where
> exactly in this 84 minute piece).
Here is my most recent blog about TDE:
https://momjian.us/main/blogs/pgblog/2025.html#February_22_2025
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
@ 2025-10-31 14:01 ` Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
0 siblings, 1 reply; 36+ messages in thread
From: Kai Wagner @ 2025-10-31 14:01 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>; pgsql-general
As I personally believe, there is no real way around TDE in the future,
either by extensibility of the core (start with the storage manager and
move your way on from there), to make an extension possible, or by directly
adding it to the core, there are more reasons coming or are already on
their way.
With the PCI DSS v4.1 standard, one key rule to comply with is, that "If
PAN is stored, it must be rendered unreadable". Of course there are other
ways, like tokenization, hashing etc. but this regulation is pushing
towards at rest encryption in the long run, and not only disk encryption.
We can dislike it, but we are already seeing the need coming from large
industries and companies that they cannot work around this anymore, as the
auditors doing the checkboxes do not really care about "good alternatives",
as they do not even technically understand what this is about. They do
compare postgres simply against other already in use databases at these
orgs (MySQL or MongoDB), and as such, we are currently the only one that
cannot be used in such a use case, at least not without the willingness of
the auditor to make it happen.
On Thu, Oct 30, 2025 at 9:00 PM Bruce Momjian <[email protected]> wrote:
> On Fri, Oct 17, 2025 at 09:01:52AM +0200, Laurenz Albe wrote:
> > On Fri, 2025-10-17 at 00:49 -0400, Ron Johnson wrote:
> > > On Thu, Oct 16, 2025 at 6:05 PM Greg Sabino Mullane <
> [email protected]> wrote:
> > > >
> > > > TDE, on the other hand, is a very complex and difficult thing to add
> into Postgres.
> > >
> > > TDE was added to SQL Server, with (to us, at least) minimally-noticed
> overhead.
> > > Oracle has it, too, but I don't know the details.
> > >
> > > The bottom line is that requirements for TDE are escalating, whether
> you like it or
> > > not, as Yet Another Layer Of Defense against hackers exfiltrating
> data, and then
> > > threatening to leak it to the public.
> >
> > Bruce Momjian has interesting things to say about that in
> >
> https://url.avanan.click/v2/r01/___https://compiledconversations.com/6/___.YXAzOnBlcmNvbmE6YTpnOjMxN...
> (unfortunately I don't remember where
> > exactly in this 84 minute piece).
>
> Here is my most recent blog about TDE:
>
>
> https://url.avanan.click/v2/r01/___https://momjian.us/main/blogs/pgblog/2025.html%23February_22_2025...
>
> --
> Bruce Momjian <[email protected]>
> https://url.avanan.click/v2/r01/___https://momjian.us___.YXAzOnBlcmNvbmE6YTpnOjMxNTMyOGQ0MzIyODAzOTU...
> EDB
> https://url.avanan.click/v2/r01/___https://enterprisedb.com___.YXAzOnBlcmNvbmE6YTpnOjMxNTMyOGQ0MzIyO...
>
> Do not let urgent matters crowd out time for investment in the future.
>
>
>
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
@ 2025-10-31 14:54 ` Bruce Momjian <[email protected]>
2025-10-31 15:21 ` Re: Enquiry about TDE with PgSQL Adrian Klaver <[email protected]>
2025-10-31 15:25 ` Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-11-01 00:16 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
0 siblings, 3 replies; 36+ messages in thread
From: Bruce Momjian @ 2025-10-31 14:54 UTC (permalink / raw)
To: Kai Wagner <[email protected]>; +Cc: Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>; pgsql-general
On Fri, Oct 31, 2025 at 03:01:48PM +0100, Kai Wagner wrote:
> As I personally believe, there is no real way around TDE in the future, either
> by extensibility of the core (start with the storage manager and move your way
> on from there), to make an extension possible, or by directly adding it to the
> core, there are more reasons coming or are already on their way.
>
> With the PCI DSS v4.1 standard, one key rule to comply with is, that "If PAN is
Uh, I think you mean the 4.0.1 standard, which became active on January
1, 2025. I am surprised this is only being mentioned now:
https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1
When will PCI DSS v4.0 be retired?
As with all new versions of PCI DSS, there will be a period where both
the current and updated version will be active at the same time. PCI DSS
--> v4.0 will be retired on 31 December 2024. After that point, PCI DSS
--> v4.0.1 will be the only active version of the standard supported by PCI
SSC.
While it was active on Jan 1, it became effective on March 31, 2025:
Does PCI DSS v4.0.1 change the 31 March 2025 effective date for the new
requirements?
No. This limited revision does not impact the effective date of these
new requirements.
> stored, it must be rendered unreadable". Of course there are other ways, like
> tokenization, hashing etc. but this regulation is pushing towards at rest
> encryption in the long run, and not only disk encryption. We can dislike it,
> but we are already seeing the need coming from large industries and companies
> that they cannot work around this anymore, as the auditors doing the checkboxes
> do not really care about "good alternatives", as they do not even technically
> understand what this is about. They do compare postgres simply against other
> already in use databases at these orgs (MySQL or MongoDB), and as such, we are
> currently the only one that cannot be used in such a use case, at least not
> without the willingness of the auditor to make it happen.
I see the new specification that disk-level encryption is insufficient,
starting on page 93 (page 97 in the PDF URL):
https://www.middlebury.edu/sites/default/files/2025-01/PCI-DSS-v4_0_1.pdf#page=97
--> 3.5.1.2 If disk-level or partition-level encryption (rather than
file-, column-, or field-level database encryption) is used to
render PAN unreadable, it is implemented only as follows:
• On removable electronic media
OR
• If used for non-removable electronic media, PAN is also
--> rendered unreadable via another mechanism that meets Requirement
3.5.1.
...
While disk or partition encryption may still be present on these
types of devices, it cannot be the only mechanism used to protect
PAN stored on those systems. Any stored PAN must also be rendered
unreadable per Requirement 3.5.1—for example, through truncation
or a data-level encryption mechanism. Full disk encryption helps
to protect data in the event of physical loss of a disk and
therefore its use is appropriate only for removable electronic
media storage devices.
Purpose
Disk-level and partition-level encryption typically encrypts
the entire disk or partition using the same key, with all data
automatically decrypted when the system runs or when an authorized
--> user requests it. For this reason, disk-level encryption is not
--> appropriate to protect stored PAN on computers, laptops, servers,
storage arrays, or any other system that provides transparent
decryption upon user authentication.
PAN is:
https://www.middlebury.edu/sites/default/files/2025-01/PCI-DSS-v4_0_1.pdf#page=391
PAN Acronym for “primary account number.” Unique payment card
number (credit, debit, or prepaid cards, etc.) that identifies
the issuer and the cardholder account.
So it seems we have somewhat of a stand-off, with the Postgres project
questioning the value of TDE and the PCI writers doubling-down on
specifying disk-level encryption as insufficient.
The biggest possible downside of this standoff is that enterprises that
need to meet PCI compliance specifications are forced to use specialized
versions of Postgres or Postgres extensions that support TDE.
The fact that it has been seven months since PCI 4.0.1 was effective,
with little to no discussion or movement on adding TDE to community
Postgres means to me that we are unlikely to see TDE added to community
Postgres anytime soon. I have a small hope that adding compression to
the writing of temporary files will reduce the code changes needed to
encrypt temporary files, thus reducing the amount of TDE code changes
needed.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
@ 2025-10-31 15:21 ` Adrian Klaver <[email protected]>
2025-10-31 16:40 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-31 17:04 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2 siblings, 2 replies; 36+ messages in thread
From: Adrian Klaver @ 2025-10-31 15:21 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; Kai Wagner <[email protected]>; +Cc: Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>; pgsql-general
On 10/31/25 07:54, Bruce Momjian wrote:
> On Fri, Oct 31, 2025 at 03:01:48PM +0100, Kai Wagner wrote:
>> With the PCI DSS v4.1 standard, one key rule to comply with is, that "If PAN is
>
> Uh, I think you mean the 4.0.1 standard, which became active on January
> 1, 2025. I am surprised this is only being mentioned now:
> So it seems we have somewhat of a stand-off, with the Postgres project
> questioning the value of TDE and the PCI writers doubling-down on
> specifying disk-level encryption as insufficient.
Yeah, what I would like to know is how many of the data breaches
actually grab directly from the storage versus getting it through the
database or other software above the storage? It seems to me social
engineering plays a bigger role in this.
--
Adrian Klaver
[email protected]
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 15:21 ` Re: Enquiry about TDE with PgSQL Adrian Klaver <[email protected]>
@ 2025-10-31 16:40 ` Laurenz Albe <[email protected]>
2025-10-31 16:49 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 17:01 ` Re: Enquiry about TDE with PgSQL Adrian Klaver <[email protected]>
1 sibling, 2 replies; 36+ messages in thread
From: Laurenz Albe @ 2025-10-31 16:40 UTC (permalink / raw)
To: Adrian Klaver <[email protected]>; Bruce Momjian <[email protected]>; Kai Wagner <[email protected]>; +Cc: Ron Johnson <[email protected]>; pgsql-general
On Fri, 2025-10-31 at 08:21 -0700, Adrian Klaver wrote:
> Yeah, what I would like to know is how many of the data breaches
> actually grab directly from the storage versus getting it through the
> database or other software above the storage? It seems to me social
> engineering plays a bigger role in this.
This is not about actual security considerations, it is about checkboxes.
Consequently, rational arguments are missing the point.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 15:21 ` Re: Enquiry about TDE with PgSQL Adrian Klaver <[email protected]>
2025-10-31 16:40 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
@ 2025-10-31 16:49 ` Bruce Momjian <[email protected]>
1 sibling, 0 replies; 36+ messages in thread
From: Bruce Momjian @ 2025-10-31 16:49 UTC (permalink / raw)
To: Laurenz Albe <[email protected]>; +Cc: Adrian Klaver <[email protected]>; Kai Wagner <[email protected]>; Ron Johnson <[email protected]>; pgsql-general
On Fri, Oct 31, 2025 at 05:40:31PM +0100, Laurenz Albe wrote:
> On Fri, 2025-10-31 at 08:21 -0700, Adrian Klaver wrote:
> > Yeah, what I would like to know is how many of the data breaches
> > actually grab directly from the storage versus getting it through the
> > database or other software above the storage? It seems to me social
> > engineering plays a bigger role in this.
>
> This is not about actual security considerations, it is about checkboxes.
> Consequently, rational arguments are missing the point.
I think the big question is that, now with the effective PCI spec
disallowing only storage-level encryption, can we, as a project,
continue to reject in-core TDE because it is a check-box item.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 15:21 ` Re: Enquiry about TDE with PgSQL Adrian Klaver <[email protected]>
2025-10-31 16:40 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
@ 2025-10-31 17:01 ` Adrian Klaver <[email protected]>
1 sibling, 0 replies; 36+ messages in thread
From: Adrian Klaver @ 2025-10-31 17:01 UTC (permalink / raw)
To: Laurenz Albe <[email protected]>; Bruce Momjian <[email protected]>; Kai Wagner <[email protected]>; +Cc: Ron Johnson <[email protected]>; pgsql-general
On 10/31/25 09:40, Laurenz Albe wrote:
> On Fri, 2025-10-31 at 08:21 -0700, Adrian Klaver wrote:
>> Yeah, what I would like to know is how many of the data breaches
>> actually grab directly from the storage versus getting it through the
>> database or other software above the storage? It seems to me social
>> engineering plays a bigger role in this.
>
> This is not about actual security considerations, it is about checkboxes.
> Consequently, rational arguments are missing the point.
Alright, been there.
Years ago I used to drive a delivery truck for wholesale greenhouse and
one of my chores was to go to a remote greenhouse we operated and
pickup/deliver plants. There was a whole process for securing the key
that you used to open the entry door. I pointed out that the greenhouse
walls where two layers of plastic inflated by an air blower and then I
proceeded to pull out my pocket knife as an example of a 'universal'
key. The door key process stayed because it made people feel the
greenhouse contents where safe. FYI, things did get stolen though that
was because folks left them outside and the thieves did not have to
bother with a knife.
>
> Yours,
> Laurenz Albe
--
Adrian Klaver
[email protected]
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 15:21 ` Re: Enquiry about TDE with PgSQL Adrian Klaver <[email protected]>
@ 2025-10-31 17:04 ` Christophe Pettus <[email protected]>
2025-10-31 17:06 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
1 sibling, 1 reply; 36+ messages in thread
From: Christophe Pettus @ 2025-10-31 17:04 UTC (permalink / raw)
To: Adrian Klaver <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Kai Wagner <[email protected]>; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>; pgsql-general
> On Oct 31, 2025, at 08:21, Adrian Klaver <[email protected]> wrote:
> Yeah, what I would like to know is how many of the data breaches actually grab directly from the storage versus getting it through the database or other software above the storage?
Essentially zero.
PCI, like a lot of data security standards, are a magpie's assemblage of things that the authors have heard about all of which sound "secure" to them. However, since these particular magpies have machine guns (metaphorically) and can do serious damage to businesses, we must play along with the masquerade.
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 15:21 ` Re: Enquiry about TDE with PgSQL Adrian Klaver <[email protected]>
2025-10-31 17:04 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
@ 2025-10-31 17:06 ` Bruce Momjian <[email protected]>
2025-10-31 17:32 ` RE: Enquiry about TDE with PgSQL Clay Jackson (cjackson) <[email protected]>
0 siblings, 1 reply; 36+ messages in thread
From: Bruce Momjian @ 2025-10-31 17:06 UTC (permalink / raw)
To: Christophe Pettus <[email protected]>; +Cc: Adrian Klaver <[email protected]>; Kai Wagner <[email protected]>; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>; pgsql-general
On Fri, Oct 31, 2025 at 10:04:35AM -0700, Christophe Pettus wrote:
>
>
> > On Oct 31, 2025, at 08:21, Adrian Klaver <[email protected]>
> > wrote: Yeah, what I would like to know is how many of the data
> > breaches actually grab directly from the storage versus getting it
> > through the database or other software above the storage?
>
> Essentially zero.
>
> PCI, like a lot of data security standards, are a magpie's assemblage
> of things that the authors have heard about all of which sound
> "secure" to them. However, since these particular magpies have
> machine guns (metaphorically) and can do serious damage to businesses,
> we must play along with the masquerade.
Yes, we have been avoiding the masquerade for years. The question is
can we continue. From the lack of discussion since April 1, 2025, it
seems the answer is yes.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
^ permalink raw reply [nested|flat] 36+ messages in thread
* RE: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 15:21 ` Re: Enquiry about TDE with PgSQL Adrian Klaver <[email protected]>
2025-10-31 17:04 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-10-31 17:06 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
@ 2025-10-31 17:32 ` Clay Jackson (cjackson) <[email protected]>
0 siblings, 0 replies; 36+ messages in thread
From: Clay Jackson (cjackson) @ 2025-10-31 17:32 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; Christophe Pettus <[email protected]>; +Cc: Adrian Klaver <[email protected]>; Kai Wagner <[email protected]>; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>; pgsql-general
Pardo me for jumping in here - but would filesystem level encryption possibly meet your requirements?
Clay Jackson
Database Solutions Sales Engineer
[email protected]
office 949-754-1203 mobile 425-802-9603
-----Original Message-----
From: Bruce Momjian <[email protected]>
Sent: Friday, October 31, 2025 10:06 AM
To: Christophe Pettus <[email protected]>
Cc: Adrian Klaver <[email protected]>; Kai Wagner <[email protected]>; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>; pgsql-general <[email protected]>
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 Fri, Oct 31, 2025 at 10:04:35AM -0700, Christophe Pettus wrote:
>
>
> > On Oct 31, 2025, at 08:21, Adrian Klaver <[email protected]>
> > wrote: Yeah, what I would like to know is how many of the data
> > breaches actually grab directly from the storage versus getting it
> > through the database or other software above the storage?
>
> Essentially zero.
>
> PCI, like a lot of data security standards, are a magpie's assemblage
> of things that the authors have heard about all of which sound
> "secure" to them. However, since these particular magpies have
> machine guns (metaphorically) and can do serious damage to businesses,
> we must play along with the masquerade.
Yes, we have been avoiding the masquerade for years. The question is can we continue. From the lack of discussion since April 1, 2025, it seems the answer is yes.
--
Bruce Momjian <[email protected]> https://momjian.us/
EDB https://enterprisedb.com/
Do not let urgent matters crowd out time for investment in the future.
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
@ 2025-10-31 15:25 ` Greg Sabino Mullane <[email protected]>
2025-10-31 15:34 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 15:34 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-31 15:37 ` Re: Enquiry about TDE with PgSQL Adrian Klaver <[email protected]>
2 siblings, 3 replies; 36+ messages in thread
From: Greg Sabino Mullane @ 2025-10-31 15:25 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Kai Wagner <[email protected]>; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>; pgsql-general
On Fri, Oct 31, 2025 at 10:54 AM Bruce Momjian <[email protected]> wrote:
> Disk-level and partition-level encryption typically encrypts
> the entire disk or partition using the same key, with all data
> automatically decrypted when the system runs or when an authorized
> --> user requests it. For this reason, disk-level encryption is not
> --> appropriate to protect stored PAN on computers, laptops, servers,
> storage arrays, or any other system that provides transparent
> decryption upon user authentication.
>
Hmm, I read this a few times but still not sure what the technical
objection is. Yes, the entire disk is encrypted with the same key, but why
is that insufficient to protect things? Anyone care to guess what they are
thinking here?
The biggest possible downside of this standoff is that enterprises that
> need to meet PCI compliance specifications are forced to use specialized
> versions of Postgres or Postgres extensions that support TDE.
>
Not always a downside for the companies selling those specialized versions
though.
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 15:25 ` Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
@ 2025-10-31 15:34 ` Bruce Momjian <[email protected]>
2 siblings, 0 replies; 36+ messages in thread
From: Bruce Momjian @ 2025-10-31 15:34 UTC (permalink / raw)
To: Greg Sabino Mullane <[email protected]>; +Cc: Kai Wagner <[email protected]>; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>; pgsql-general
On Fri, Oct 31, 2025 at 11:25:04AM -0400, Greg Sabino Mullane wrote:
> On Fri, Oct 31, 2025 at 10:54 AM Bruce Momjian <[email protected]> wrote:
>
> Disk-level and partition-level encryption typically encrypts
> the entire disk or partition using the same key, with all data
> automatically decrypted when the system runs or when an authorized
> --> user requests it. For this reason, disk-level encryption is not
> --> appropriate to protect stored PAN on computers, laptops, servers,
> storage arrays, or any other system that provides transparent
> decryption upon user authentication.
>
>
> Hmm, I read this a few times but still not sure what the technical objection
> is. Yes, the entire disk is encrypted with the same key, but why is that
> insufficient to protect things? Anyone care to guess what they are thinking
> here?
This is more an argument for security using layers. With storage
encryption, the file system as visible is unencrypted, and backups of
that file system can be unencrypted.
Community Postgres relies on file system permissions to secure the data
directory. You can argue that once file system permissions are
bypassed, security is impossible, and agree with that, but some feel the
extra step needed to pull the Postgres encryption key from memory is a
security feature. And for backups, the Postgres encryption key might
not be in memory. Of course, forcing encrypted backups is a solution,
but an extra step.
> The biggest possible downside of this standoff is that enterprises that
> need to meet PCI compliance specifications are forced to use specialized
> versions of Postgres or Postgres extensions that support TDE.
>
> Not always a downside for the companies selling those specialized versions
> though.
Yes, no question they are happy.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 15:25 ` Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
@ 2025-10-31 15:34 ` Ron Johnson <[email protected]>
2 siblings, 0 replies; 36+ messages in thread
From: Ron Johnson @ 2025-10-31 15:34 UTC (permalink / raw)
To: pgsql-general
On Fri, Oct 31, 2025 at 11:25 AM Greg Sabino Mullane <[email protected]>
wrote:
> On Fri, Oct 31, 2025 at 10:54 AM Bruce Momjian <[email protected]> wrote:
>
>> Disk-level and partition-level encryption typically encrypts
>> the entire disk or partition using the same key, with all data
>> automatically decrypted when the system runs or when an authorized
>> --> user requests it. For this reason, disk-level encryption is not
>> --> appropriate to protect stored PAN on computers, laptops, servers,
>> storage arrays, or any other system that provides transparent
>> decryption upon user authentication.
>>
>
> Hmm, I read this a few times but still not sure what the technical
> objection is. Yes, the entire disk is encrypted with the same key, but why
> is that insufficient to protect things? Anyone care to guess what they are
> thinking here?
>
Networking.
Who breaks into a DC and steals a rack of disks or SSDs? Very, very few
evil-doers.
Who hacks into networks and exfiltrates data over the wire? Many hackers.
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 15:25 ` Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
@ 2025-10-31 15:37 ` Adrian Klaver <[email protected]>
2 siblings, 0 replies; 36+ messages in thread
From: Adrian Klaver @ 2025-10-31 15:37 UTC (permalink / raw)
To: Greg Sabino Mullane <[email protected]>; Bruce Momjian <[email protected]>; +Cc: Kai Wagner <[email protected]>; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>; pgsql-general
On 10/31/25 08:25, Greg Sabino Mullane wrote:
> On Fri, Oct 31, 2025 at 10:54 AM Bruce Momjian <[email protected]
> <mailto:[email protected]>> wrote:
>
> Disk-level and partition-level encryption typically encrypts
> the entire disk or partition using the same key, with all data
> automatically decrypted when the system runs or when an
> authorized
> --> user requests it. For this reason, disk-level encryption is not
> --> appropriate to protect stored PAN on computers, laptops,
> servers,
> storage arrays, or any other system that provides transparent
> decryption upon user authentication.
>
>
> Hmm, I read this a few times but still not sure what the technical
> objection is. Yes, the entire disk is encrypted with the same key, but
> why is that insufficient to protect things? Anyone care to guess what
> they are thinking here?
My best guess, is that the more the storage encryption is fragmented by
different keys the less likely all the disk could be decrypted by a
single action. The weak link is '... other system that provides
transparent decryption upon user authentication.'. At some point the
data needs to be decrypted for end user use. That means the point of
attack is moved to the user and storage encryption does not really matter.
>
> The biggest possible downside of this standoff is that enterprises
> that need to meet PCI compliance specifications are forced to use
> specialized versions of Postgres or Postgres extensions that support
> TDE.
>
>
> Not always a downside for the companies selling those specialized
> versions though.
>
> Cheers,
> Greg
>
> --
> Crunchy Data - https://www.crunchydata.com <https://www.crunchydata.com;
> Enterprise Postgres Software Products & Tech Support
>
--
Adrian Klaver
[email protected]
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
@ 2025-11-01 00:16 ` Christophe Pettus <[email protected]>
2025-11-01 00:21 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2 siblings, 1 reply; 36+ messages in thread
From: Christophe Pettus @ 2025-11-01 00:16 UTC (permalink / raw)
To: pgsql-general; +Cc: Kai Wagner <[email protected]>; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>; Bruce Momjian <[email protected]>
On Oct 31, 2025, at 07:54, Bruce Momjian <[email protected]> wrote:
> So it seems we have somewhat of a stand-off, with the Postgres project
> questioning the value of TDE and the PCI writers doubling-down on
> specifying disk-level encryption as insufficient.
PCI definitely exhibits a preference away from disk-level encryption, although it doesn't prohibit it: you have to make sure that simply mounting the disk doesn't decrypt it. Their concern is that if user credentials are compromised, and an attacker then has to do something else in order to see the plaintext. This kind of implies TDE, although they don't use that term.
Now, the road forks here:
1. If a customer wants TDE and isn't interested in hearing about other solutions, then TDE is only thing that will meet that goal.
2. The PCI spec doesn't specifically offer up TDE as an alternative to disk-level encryption, though. It exhibits a strong preference for column-level encryption of sensitive data, which doesn't require TDE.
In some ways, there's no real point of discussion. You can comply with PCI without TDE (I would argue that, in fact, you are in a better position with column-level encryption), but if the organization wants TDE, then the technical arguments rarely matter.
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:16 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
@ 2025-11-01 00:21 ` Bruce Momjian <[email protected]>
2025-11-01 00:24 ` RE: Enquiry about TDE with PgSQL Clay Jackson (cjackson) <[email protected]>
2025-11-01 01:32 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
0 siblings, 2 replies; 36+ messages in thread
From: Bruce Momjian @ 2025-11-01 00:21 UTC (permalink / raw)
To: Christophe Pettus <[email protected]>; +Cc: pgsql-general; Kai Wagner <[email protected]>; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>
On Fri, Oct 31, 2025 at 05:16:09PM -0700, Christophe Pettus wrote:
> On Oct 31, 2025, at 07:54, Bruce Momjian <[email protected]> wrote:
> > So it seems we have somewhat of a stand-off, with the Postgres
> > project questioning the value of TDE and the PCI writers
> > doubling-down on specifying disk-level encryption as insufficient.
>
> PCI definitely exhibits a preference away from disk-level encryption,
> although it doesn't prohibit it: you have to make sure that simply
> mounting the disk doesn't decrypt it. Their concern is that if
> user credentials are compromised, and an attacker then has to do
> something else in order to see the plaintext. This kind of implies
> TDE, although they don't use that term.
>
> Now, the road forks here:
>
> 1. If a customer wants TDE and isn't interested in hearing about other
> solutions, then TDE is only thing that will meet that goal.
>
> 2. The PCI spec doesn't specifically offer up TDE as an alternative to
> disk-level encryption, though. It exhibits a strong preference for
> column-level encryption of sensitive data, which doesn't require TDE.
>
> In some ways, there's no real point of discussion. You can comply
> with PCI without TDE (I would argue that, in fact, you are in a better
> position with column-level encryption), but if the organization wants
> TDE, then the technical arguments rarely matter.
I think column-level encryption, on the client side, actually does
improve security and is preferable to file system level TDE, and I think
many here feel the same way.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
^ permalink raw reply [nested|flat] 36+ messages in thread
* RE: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:16 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 00:21 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
@ 2025-11-01 00:24 ` Clay Jackson (cjackson) <[email protected]>
2025-11-01 00:33 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 01:35 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
1 sibling, 2 replies; 36+ messages in thread
From: Clay Jackson (cjackson) @ 2025-11-01 00:24 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; Christophe Pettus <[email protected]>; +Cc: pgsql-general; Kai Wagner <[email protected]>; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>
I can't disagree - but the question them becomes, as Markus and other have pointed out; would that allow a customer/user to check the "Encryption" box for PCI or any other "compliance review"
Clay Jackson
Database Solutions Sales Engineer
[email protected]
office 949-754-1203 mobile 425-802-9603
-----Original Message-----
From: Bruce Momjian <[email protected]>
Sent: Friday, October 31, 2025 5:21 PM
To: Christophe Pettus <[email protected]>
Cc: pgsql-general <[email protected]>; Kai Wagner <[email protected]>; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>
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 Fri, Oct 31, 2025 at 05:16:09PM -0700, Christophe Pettus wrote:
> On Oct 31, 2025, at 07:54, Bruce Momjian <[email protected]> wrote:
> > So it seems we have somewhat of a stand-off, with the Postgres
> > project questioning the value of TDE and the PCI writers
> > doubling-down on specifying disk-level encryption as insufficient.
>
> PCI definitely exhibits a preference away from disk-level encryption,
> although it doesn't prohibit it: you have to make sure that simply
> mounting the disk doesn't decrypt it. Their concern is that if user
> credentials are compromised, and an attacker then has to do something
> else in order to see the plaintext. This kind of implies TDE,
> although they don't use that term.
>
> Now, the road forks here:
>
> 1. If a customer wants TDE and isn't interested in hearing about other
> solutions, then TDE is only thing that will meet that goal.
>
> 2. The PCI spec doesn't specifically offer up TDE as an alternative to
> disk-level encryption, though. It exhibits a strong preference for
> column-level encryption of sensitive data, which doesn't require TDE.
>
> In some ways, there's no real point of discussion. You can comply
> with PCI without TDE (I would argue that, in fact, you are in a better
> position with column-level encryption), but if the organization wants
> TDE, then the technical arguments rarely matter.
I think column-level encryption, on the client side, actually does improve security and is preferable to file system level TDE, and I think many here feel the same way.
--
Bruce Momjian <[email protected]> https://momjian.us/
EDB https://enterprisedb.com/
Do not let urgent matters crowd out time for investment in the future.
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:16 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 00:21 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:24 ` RE: Enquiry about TDE with PgSQL Clay Jackson (cjackson) <[email protected]>
@ 2025-11-01 00:33 ` Bruce Momjian <[email protected]>
1 sibling, 0 replies; 36+ messages in thread
From: Bruce Momjian @ 2025-11-01 00:33 UTC (permalink / raw)
To: Clay Jackson (cjackson) <[email protected]>; +Cc: Christophe Pettus <[email protected]>; pgsql-general; Kai Wagner <[email protected]>; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>
On Sat, Nov 1, 2025 at 12:24:25AM +0000, Clay Jackson (cjackson) wrote:
> I can't disagree - but the question them becomes, as Markus and
> other have pointed out; would that allow a customer/user to check the
> "Encryption" box for PCI or any other "compliance review"
I think so. It says storage encryption is insufficient, but it doesn't
say client-side column-level encryption is insufficient.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:16 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 00:21 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:24 ` RE: Enquiry about TDE with PgSQL Clay Jackson (cjackson) <[email protected]>
@ 2025-11-01 01:35 ` Christophe Pettus <[email protected]>
2025-11-01 04:18 ` Re: Enquiry about TDE with PgSQL Chris Travers <[email protected]>
1 sibling, 1 reply; 36+ messages in thread
From: Christophe Pettus @ 2025-11-01 01:35 UTC (permalink / raw)
To: Clay Jackson (cjackson) <[email protected]>; +Cc: Bruce Momjian <[email protected]>; pgsql-general; Kai Wagner <[email protected]>; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>
On Oct 31, 2025, at 17:24, Clay Jackson (cjackson) <[email protected]> wrote:
>
> I can't disagree - but the question them becomes, as Markus and other have pointed out; would that allow a customer/user to check the "Encryption" box for PCI or any other "compliance review"
The answer is: it depends (doesn't it always?). Doing secure column-level encryption meets the PCI standard, and a competent PCI auditor will know that. However, TDE has this cache as being "the way one does it," and if the organization is that way, it's hard to move them off of it.
As a sign of how the PCI world views TDE, at least one of the major credit card associations does not use it, and they have literally everyone's credit card number, with expiration date and CVV, sitting on their disks.
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:16 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 00:21 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:24 ` RE: Enquiry about TDE with PgSQL Clay Jackson (cjackson) <[email protected]>
2025-11-01 01:35 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
@ 2025-11-01 04:18 ` Chris Travers <[email protected]>
2025-11-01 07:34 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
0 siblings, 1 reply; 36+ messages in thread
From: Chris Travers @ 2025-11-01 04:18 UTC (permalink / raw)
To: Christophe Pettus <[email protected]>; +Cc: Clay Jackson (cjackson) <[email protected]>; Bruce Momjian <[email protected]>; pgsql-general; Kai Wagner <[email protected]>; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>
I maintain that the way forward is to get TDE in core. Perhaps someone
could pick up the previous patches and try to push them again
Best Wishes,
Chris Travers
On Sat, Nov 1, 2025, 8:36 AM Christophe Pettus <[email protected]> wrote:
> On Oct 31, 2025, at 17:24, Clay Jackson (cjackson) <[email protected]>
> wrote:
> >
> > I can't disagree - but the question them becomes, as Markus and other
> have pointed out; would that allow a customer/user to check the
> "Encryption" box for PCI or any other "compliance review"
>
> The answer is: it depends (doesn't it always?). Doing secure column-level
> encryption meets the PCI standard, and a competent PCI auditor will know
> that. However, TDE has this cache as being "the way one does it," and if
> the organization is that way, it's hard to move them off of it.
>
> As a sign of how the PCI world views TDE, at least one of the major credit
> card associations does not use it, and they have literally everyone's
> credit card number, with expiration date and CVV, sitting on their disks.
>
>
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:16 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 00:21 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:24 ` RE: Enquiry about TDE with PgSQL Clay Jackson (cjackson) <[email protected]>
2025-11-01 01:35 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 04:18 ` Re: Enquiry about TDE with PgSQL Chris Travers <[email protected]>
@ 2025-11-01 07:34 ` Kai Wagner <[email protected]>
2025-11-01 13:58 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
0 siblings, 1 reply; 36+ messages in thread
From: Kai Wagner @ 2025-11-01 07:34 UTC (permalink / raw)
To: Chris Travers <[email protected]>; +Cc: Christophe Pettus <[email protected]>; Clay Jackson (cjackson) <[email protected]>; Bruce Momjian <[email protected]>; pgsql-general; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>
On Sat, Nov 1, 2025 at 5:19 AM Chris Travers <[email protected]>
wrote:
> I maintain that the way forward is to get TDE in core. Perhaps someone
> could pick up the previous patches and try to push them again
>
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 <[email protected]> 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?!
>
> Best Wishes,
> Chris Travers
>
>
> On Sat, Nov 1, 2025, 8:36 AM Christophe Pettus <[email protected]> wrote:
>
>> On Oct 31, 2025, at 17:24, Clay Jackson (cjackson) <
>> [email protected]> wrote:
>> >
>> > I can't disagree - but the question them becomes, as Markus and other
>> have pointed out; would that allow a customer/user to check the
>> "Encryption" box for PCI or any other "compliance review"
>>
>> The answer is: it depends (doesn't it always?). Doing secure
>> column-level encryption meets the PCI standard, and a competent PCI auditor
>> will know that. However, TDE has this cache as being "the way one does
>> it," and if the organization is that way, it's hard to move them off of it.
>>
>> As a sign of how the PCI world views TDE, at least one of the major
>> credit card associations does not use it, and they have literally
>> everyone's credit card number, with expiration date and CVV, sitting on
>> their disks.
>>
>>
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:16 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 00:21 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:24 ` RE: Enquiry about TDE with PgSQL Clay Jackson (cjackson) <[email protected]>
2025-11-01 01:35 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 04:18 ` Re: Enquiry about TDE with PgSQL Chris Travers <[email protected]>
2025-11-01 07:34 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
@ 2025-11-01 13:58 ` Bruce Momjian <[email protected]>
2025-11-01 15:32 ` Re: Enquiry about TDE with PgSQL Adrian Klaver <[email protected]>
2025-11-02 10:14 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
0 siblings, 2 replies; 36+ messages in thread
From: Bruce Momjian @ 2025-11-01 13:58 UTC (permalink / raw)
To: Kai Wagner <[email protected]>; +Cc: Chris Travers <[email protected]>; Christophe Pettus <[email protected]>; Clay Jackson (cjackson) <[email protected]>; pgsql-general; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>
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 <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:16 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 00:21 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:24 ` RE: Enquiry about TDE with PgSQL Clay Jackson (cjackson) <[email protected]>
2025-11-01 01:35 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 04:18 ` Re: Enquiry about TDE with PgSQL Chris Travers <[email protected]>
2025-11-01 07:34 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-11-01 13:58 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
@ 2025-11-01 15:32 ` Adrian Klaver <[email protected]>
2025-11-01 18:34 ` Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
1 sibling, 1 reply; 36+ messages in thread
From: Adrian Klaver @ 2025-11-01 15:32 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; Kai Wagner <[email protected]>; +Cc: Chris Travers <[email protected]>; Christophe Pettus <[email protected]>; Clay Jackson (cjackson) <[email protected]>; pgsql-general; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>
On 11/1/25 06:58, Bruce Momjian wrote:
> On Sat, Nov 1, 2025 at 08:34:57AM +0100, Kai Wagner wrote:
> 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.
>
That is not true:
https://docs.percona.com/pg-tde/index.html
and
https://www.cybertec-postgresql.com/en/products/postgresql-transparent-data-encryption/
The community does provide it, just not the version of Postgres released
here:
https://www.postgresql.org/download/
--
Adrian Klaver
[email protected]
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:16 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 00:21 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:24 ` RE: Enquiry about TDE with PgSQL Clay Jackson (cjackson) <[email protected]>
2025-11-01 01:35 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 04:18 ` Re: Enquiry about TDE with PgSQL Chris Travers <[email protected]>
2025-11-01 07:34 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-11-01 13:58 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 15:32 ` Re: Enquiry about TDE with PgSQL Adrian Klaver <[email protected]>
@ 2025-11-01 18:34 ` Greg Sabino Mullane <[email protected]>
2025-11-01 18:54 ` Re: Enquiry about TDE with PgSQL Ken Marshall <[email protected]>
2025-11-01 21:15 ` Re: Enquiry about TDE with PgSQL Adrian Klaver <[email protected]>
0 siblings, 2 replies; 36+ messages in thread
From: Greg Sabino Mullane @ 2025-11-01 18:34 UTC (permalink / raw)
To: Adrian Klaver <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Kai Wagner <[email protected]>; Chris Travers <[email protected]>; Christophe Pettus <[email protected]>; Clay Jackson (cjackson) <[email protected]>; pgsql-general; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>
On Sat, Nov 1, 2025 at 11:32 AM Adrian Klaver <[email protected]>
wrote:
> The community does provide it, just not the version of Postgres released
> here:
>
I'm not sure of your point here. Companies have forked versions / patches,
yes, but not sure how that equates to "community-provided"
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:16 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 00:21 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:24 ` RE: Enquiry about TDE with PgSQL Clay Jackson (cjackson) <[email protected]>
2025-11-01 01:35 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 04:18 ` Re: Enquiry about TDE with PgSQL Chris Travers <[email protected]>
2025-11-01 07:34 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-11-01 13:58 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 15:32 ` Re: Enquiry about TDE with PgSQL Adrian Klaver <[email protected]>
2025-11-01 18:34 ` Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
@ 2025-11-01 18:54 ` Ken Marshall <[email protected]>
2025-11-01 20:07 ` Re: Enquiry about TDE with PgSQL Rainer Duffner <[email protected]>
1 sibling, 1 reply; 36+ messages in thread
From: Ken Marshall @ 2025-11-01 18:54 UTC (permalink / raw)
To: pgsql-general; +Cc: pgsql-general
+1 from me for having TDE in-core or available as an extension
The security auditors that I have worked with have been increasingly
unwilling to actual evaluate the merits of an implementation or perhaps
no longer have the knowledge or skills needed. This is a needed
checkbox to allow PostgreSQL to be deployed in those environments.
Regards,
Ken
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:16 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 00:21 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:24 ` RE: Enquiry about TDE with PgSQL Clay Jackson (cjackson) <[email protected]>
2025-11-01 01:35 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 04:18 ` Re: Enquiry about TDE with PgSQL Chris Travers <[email protected]>
2025-11-01 07:34 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-11-01 13:58 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 15:32 ` Re: Enquiry about TDE with PgSQL Adrian Klaver <[email protected]>
2025-11-01 18:34 ` Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-11-01 18:54 ` Re: Enquiry about TDE with PgSQL Ken Marshall <[email protected]>
@ 2025-11-01 20:07 ` Rainer Duffner <[email protected]>
0 siblings, 0 replies; 36+ messages in thread
From: Rainer Duffner @ 2025-11-01 20:07 UTC (permalink / raw)
To: Ken Marshall <[email protected]>; +Cc: pgsql-general
> Am 01.11.2025 um 19:54 schrieb Ken Marshall <[email protected]>:
>
> +1 from me for having TDE in-core or available as an extension
>
> The security auditors that I have worked with have been increasingly
> unwilling to actual evaluate the merits of an implementation or perhaps
> no longer have the knowledge or skills needed. This is a needed
> checkbox to allow PostgreSQL to be deployed in those environments.
>
>
Do you actually have HSMs with your TDE (assuming you use it elsewhere?
We run, for a customer, an Oracle DataGuard configuration with TDE with a HSM.
We have a support-contract with a 3rd party company that helps us with the more obscure problems on Oracle that we don’t encounter every day and they told us of all their clients (banks, insurance companies), we are the only ones with TDE. They loath working with it ;-)
There’s apparently another non-disclosed customer that uses it.
It may be that a lot of people now use „cloud HSMs“ - but I’m a bit of a purist for these kinds of things in that I believe that unless you own the hardware (HSMs are usually tamper-proof enough so you can deploy them in 3rd-party datacenters that aren’t your own), you don’t really control the keys.
In our case, the databases are backed up with rman to an NFS share that is provided by a virtualized linux server - the severs itself are hardware.
If you don’t have TDE, your backups aren’t encrypted and they end up on the veeam server like everything else, where an admin could copy them somewhere else and potentially take them elsewhere.
With the HSM, we don’t actually know the secret to decrypt the data (there may be a way to get it, I don’t know). We know the secret to unseal the wallet (that sits on the HSM, I believe) so that the database actually mounts and starts.
It’s pretty bullet-proof (I believe there’s techniques to prevent sniffing out the secret from RAM and HSMs usually implement those in their client software).
In fact, it’s so bullet-proof that should you lose the keys on the HSM, your data is gone if you have no other backups or backups of the HSM.
If the amount of data is small enough, you can GPG encrypt a „normal“ full dump - but that become unfeasible as database size grows.
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:16 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 00:21 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:24 ` RE: Enquiry about TDE with PgSQL Clay Jackson (cjackson) <[email protected]>
2025-11-01 01:35 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 04:18 ` Re: Enquiry about TDE with PgSQL Chris Travers <[email protected]>
2025-11-01 07:34 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-11-01 13:58 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 15:32 ` Re: Enquiry about TDE with PgSQL Adrian Klaver <[email protected]>
2025-11-01 18:34 ` Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
@ 2025-11-01 21:15 ` Adrian Klaver <[email protected]>
2025-11-01 23:42 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
1 sibling, 1 reply; 36+ messages in thread
From: Adrian Klaver @ 2025-11-01 21:15 UTC (permalink / raw)
To: Greg Sabino Mullane <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Kai Wagner <[email protected]>; Chris Travers <[email protected]>; Christophe Pettus <[email protected]>; Clay Jackson (cjackson) <[email protected]>; pgsql-general; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>
On 11/1/25 11:34, Greg Sabino Mullane wrote:
> On Sat, Nov 1, 2025 at 11:32 AM Adrian Klaver <[email protected]
> <mailto:[email protected]>> wrote:
>
> The community does provide it, just not the version of Postgres
> released here:
>
>
> I'm not sure of your point here. Companies have forked versions /
> patches, yes, but not sure how that equates to "community-provided"
Well this gets in to a pet peeve of my with regard to OSS and the
definition of 'community', it seems to adjust in size of coverage
depending on the argument.
For a recent thread on -www that gets into this, as concerns
contributors, see:
https://www.postgresql.org/message-id/aJ9ur1eSnk5pp9aD%40msg.df7cb.de
To get to said contributors list you go:
https://www.postgresql.org/community/contributors/
where you see folks recognized for their work outside the core code.
Examples of the expanded 'commmunity':
1) From the 'community' site you can go to:
https://www.postgresql.org/download/
where that packaging is done outside of core.
2) Again from postgresql.org:
https://www.postgresql.org/docs/18/external-extensions.html
"PostgreSQL is designed to be easily extensible. For this reason,
extensions loaded into the database can function just like features that
are built in. The contrib/ directory shipped with the source code
contains several extensions, which are described in Appendix F. Other
extensions are developed independently, like PostGIS. Even PostgreSQL
replication solutions can be developed externally. For example, Slony-I
is a popular primary/standby replication solution that is developed
independently from the core project."
3) Of course there is:
https://www.postgresql.org/community/
"PostgreSQL is well-supported by its active community."
To me that means extensions provided by members of the 'community' are
'community-provided'?
>
> Cheers,
> Greg
>
> --
> Crunchy Data - https://www.crunchydata.com <https://www.crunchydata.com;
> Enterprise Postgres Software Products & Tech Support
>
--
Adrian Klaver
[email protected]
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:16 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 00:21 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:24 ` RE: Enquiry about TDE with PgSQL Clay Jackson (cjackson) <[email protected]>
2025-11-01 01:35 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 04:18 ` Re: Enquiry about TDE with PgSQL Chris Travers <[email protected]>
2025-11-01 07:34 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-11-01 13:58 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 15:32 ` Re: Enquiry about TDE with PgSQL Adrian Klaver <[email protected]>
2025-11-01 18:34 ` Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-11-01 21:15 ` Re: Enquiry about TDE with PgSQL Adrian Klaver <[email protected]>
@ 2025-11-01 23:42 ` Bruce Momjian <[email protected]>
0 siblings, 0 replies; 36+ messages in thread
From: Bruce Momjian @ 2025-11-01 23:42 UTC (permalink / raw)
To: Adrian Klaver <[email protected]>; +Cc: Greg Sabino Mullane <[email protected]>; Kai Wagner <[email protected]>; Chris Travers <[email protected]>; Christophe Pettus <[email protected]>; Clay Jackson (cjackson) <[email protected]>; pgsql-general; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>
On Sat, Nov 1, 2025 at 02:15:43PM -0700, Adrian Klaver wrote:
> 3) Of course there is:
>
> https://www.postgresql.org/community/
>
> "PostgreSQL is well-supported by its active community."
>
>
> To me that means extensions provided by members of the 'community' are
> 'community-provided'?
Yes, this point was so prone to confusion I decided not to reply to the
original email. ;-)
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:16 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 00:21 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:24 ` RE: Enquiry about TDE with PgSQL Clay Jackson (cjackson) <[email protected]>
2025-11-01 01:35 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 04:18 ` Re: Enquiry about TDE with PgSQL Chris Travers <[email protected]>
2025-11-01 07:34 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-11-01 13:58 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
@ 2025-11-02 10:14 ` Kai Wagner <[email protected]>
2025-11-03 16:56 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
1 sibling, 1 reply; 36+ messages in thread
From: Kai Wagner @ 2025-11-02 10:14 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Chris Travers <[email protected]>; Christophe Pettus <[email protected]>; Clay Jackson (cjackson) <[email protected]>; pgsql-general; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>
On Sat, Nov 1, 2025 at 2:58 PM Bruce Momjian <[email protected]> wrote:
> 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.
>
I fully agree here, and as I stated above, I don't question this at all, as
this is the strength of the diverse and spread community. Looking at this
thread alone, and the multiple different "users" popping up, that see the
need and would like to see TDE in core or in an extension drives my
thinking as it makes sense to start thinking and looking into the temp file
compression already right now, if and how this could make our code changes
easier, or if additional extensibility should be directly part of the first
patch, so you can enable it through its extension. Either way, it should be
considered and kept in mind now, not after the fact, or we will continue to
spin this wheel. And this thinking and willingness alone, to actually be
open to that idea, requires some upfront discussion, so you at least know
you are welcome to work on it without wasting effort, because no one will
ever want to merge. (and yes, of course everyone can work on whatever they
want at any point in time, but people might prefer working on something
that actually benefits the project and is welcome, rather than ending in
>/dev/null)
Given your experience Bruce, can you offer us some advice on how you would
approach it currently? What do you think makes the most sense, and how
should we proceed with collaboration to at least see a small change in
making this happen in the future?
>
> 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.
>
And this should always be at the forefront, as this makes the project
exactly as strong as it is today.
>
> --
> Bruce Momjian <[email protected]>
> https://url.avanan.click/v2/r01/___https://momjian.us___.YXAzOnBlcmNvbmE6YTpnOmZhM2VjN2JlNjcyOTZmMGQ...
> EDB
> https://url.avanan.click/v2/r01/___https://enterprisedb.com___.YXAzOnBlcmNvbmE6YTpnOmZhM2VjN2JlNjcyO...
>
> Do not let urgent matters crowd out time for investment in the future.
>
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:16 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 00:21 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:24 ` RE: Enquiry about TDE with PgSQL Clay Jackson (cjackson) <[email protected]>
2025-11-01 01:35 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 04:18 ` Re: Enquiry about TDE with PgSQL Chris Travers <[email protected]>
2025-11-01 07:34 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-11-01 13:58 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-02 10:14 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
@ 2025-11-03 16:56 ` Bruce Momjian <[email protected]>
2025-11-03 18:42 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
0 siblings, 1 reply; 36+ messages in thread
From: Bruce Momjian @ 2025-11-03 16:56 UTC (permalink / raw)
To: Kai Wagner <[email protected]>; +Cc: Chris Travers <[email protected]>; Christophe Pettus <[email protected]>; Clay Jackson (cjackson) <[email protected]>; pgsql-general; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>
On Sun, Nov 2, 2025 at 11:14:58AM +0100, Kai Wagner wrote:
> I fully agree here, and as I stated above, I don't question this at all, as
> this is the strength of the diverse and spread community. Looking at this
> thread alone, and the multiple different "users" popping up, that see the need
> and would like to see TDE in core or in an extension drives my thinking as it
> makes sense to start thinking and looking into the temp file compression
> already right now, if and how this could make our code changes easier, or if
> additional extensibility should be directly part of the first patch, so you can
> enable it through its extension. Either way, it should be considered and kept
> in mind now, not after the fact, or we will continue to spin this wheel. And
> this thinking and willingness alone, to actually be open to that idea, requires
> some upfront discussion, so you at least know you are welcome to work on it
> without wasting effort, because no one will ever want to merge. (and yes, of
> course everyone can work on whatever they want at any point in time, but people
> might prefer working on something that actually benefits the project and is
> welcome, rather than ending in >/dev/null)
>
> Given your experience Bruce, can you offer us some advice on how you would
> approach it currently? What do you think makes the most sense, and how should
> we proceed with collaboration to at least see a small change in making this
> happen in the future?
Good questions. I think we have to decide if the community wants TDE,
and if so how much code change will the community accept to get it. And
then we have to decide if this happens in an extension, like Percona's,
or in the core code.
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. (I
fortunately attended all the Percona TDE talks at the Riga conference.)
The community needs to get involved with that extension if it is to
become a community-polished solution.
An extension does allow for fewer core code changes, but as I stated in
a previous email, the changes needed for command-line tools, external
tools, and replication to work in a TDE environment could make an
extension-based-TDE API too complex to be useful.
As far as how to move forward, I think we need to look at the temporary
file compression patch, see if that will help TDE code impact, and then
decide, with that patch, if the TDE core code impact is acceptable. If
not, we then need to look at an extension, what hooks are needed, and
then decide if the final result have a simple enough API to be useful.
(Do we start from scratch or use Percona's?) If the API is complex, and
could lead to corruption/data loss due to encryption, that solution is
unacceptable.
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:16 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 00:21 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:24 ` RE: Enquiry about TDE with PgSQL Clay Jackson (cjackson) <[email protected]>
2025-11-01 01:35 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 04:18 ` Re: Enquiry about TDE with PgSQL Chris Travers <[email protected]>
2025-11-01 07:34 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-11-01 13:58 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-02 10:14 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-11-03 16:56 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
@ 2025-11-03 18:42 ` Laurenz Albe <[email protected]>
0 siblings, 0 replies; 36+ messages in thread
From: Laurenz Albe @ 2025-11-03 18:42 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; Kai Wagner <[email protected]>; +Cc: Chris Travers <[email protected]>; Christophe Pettus <[email protected]>; Clay Jackson (cjackson) <[email protected]>; pgsql-general; Ron Johnson <[email protected]>
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.
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.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 36+ messages in thread
* Re: Enquiry about TDE with PgSQL
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Re: Enquiry about TDE with PgSQL Ron Johnson <[email protected]>
2025-10-17 07:01 ` Re: Enquiry about TDE with PgSQL Laurenz Albe <[email protected]>
2025-10-30 19:59 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Re: Enquiry about TDE with PgSQL Kai Wagner <[email protected]>
2025-10-31 14:54 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
2025-11-01 00:16 ` Re: Enquiry about TDE with PgSQL Christophe Pettus <[email protected]>
2025-11-01 00:21 ` Re: Enquiry about TDE with PgSQL Bruce Momjian <[email protected]>
@ 2025-11-01 01:32 ` Christophe Pettus <[email protected]>
1 sibling, 0 replies; 36+ messages in thread
From: Christophe Pettus @ 2025-11-01 01:32 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: pgsql-general; Kai Wagner <[email protected]>; Laurenz Albe <[email protected]>; Ron Johnson <[email protected]>
> On Oct 31, 2025, at 17:21, Bruce Momjian <[email protected]> wrote:
>
> I think column-level encryption, on the client side, actually does
> improve security and is preferable to file system level TDE, and I think
> many here feel the same way.
Absolutely. Unfortunately, too many IT security policies are basically a grab-bag of things that someone has read that all claimed to be "best practice," and the degree to which they can be educated on the topic is variable.
^ permalink raw reply [nested|flat] 36+ messages in thread
end of thread, other threads:[~2025-11-03 18:42 UTC | newest]
Thread overview: 36+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-10-16 22:04 Re: Enquiry about TDE with PgSQL Greg Sabino Mullane <[email protected]>
2025-10-17 04:49 ` Ron Johnson <[email protected]>
2025-10-17 07:01 ` Laurenz Albe <[email protected]>
2025-10-17 12:47 ` Ron Johnson <[email protected]>
2025-10-30 19:59 ` Bruce Momjian <[email protected]>
2025-10-31 14:01 ` Kai Wagner <[email protected]>
2025-10-31 14:54 ` Bruce Momjian <[email protected]>
2025-10-31 15:21 ` Adrian Klaver <[email protected]>
2025-10-31 16:40 ` Laurenz Albe <[email protected]>
2025-10-31 16:49 ` Bruce Momjian <[email protected]>
2025-10-31 17:01 ` Adrian Klaver <[email protected]>
2025-10-31 17:04 ` Christophe Pettus <[email protected]>
2025-10-31 17:06 ` Bruce Momjian <[email protected]>
2025-10-31 17:32 ` Clay Jackson (cjackson) <[email protected]>
2025-10-31 15:25 ` Greg Sabino Mullane <[email protected]>
2025-10-31 15:34 ` Bruce Momjian <[email protected]>
2025-10-31 15:34 ` Ron Johnson <[email protected]>
2025-10-31 15:37 ` Adrian Klaver <[email protected]>
2025-11-01 00:16 ` Christophe Pettus <[email protected]>
2025-11-01 00:21 ` Bruce Momjian <[email protected]>
2025-11-01 00:24 ` Clay Jackson (cjackson) <[email protected]>
2025-11-01 00:33 ` Bruce Momjian <[email protected]>
2025-11-01 01:35 ` Christophe Pettus <[email protected]>
2025-11-01 04:18 ` Chris Travers <[email protected]>
2025-11-01 07:34 ` Kai Wagner <[email protected]>
2025-11-01 13:58 ` Bruce Momjian <[email protected]>
2025-11-01 15:32 ` Adrian Klaver <[email protected]>
2025-11-01 18:34 ` Greg Sabino Mullane <[email protected]>
2025-11-01 18:54 ` Ken Marshall <[email protected]>
2025-11-01 20:07 ` Rainer Duffner <[email protected]>
2025-11-01 21:15 ` Adrian Klaver <[email protected]>
2025-11-01 23:42 ` Bruce Momjian <[email protected]>
2025-11-02 10:14 ` Kai Wagner <[email protected]>
2025-11-03 16:56 ` Bruce Momjian <[email protected]>
2025-11-03 18:42 ` Laurenz Albe <[email protected]>
2025-11-01 01:32 ` Christophe Pettus <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox