Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vGwJ2-008Uwc-Ae for pgsql-general@arkaria.postgresql.org; Thu, 06 Nov 2025 09:29:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1vGwJ0-006biC-Bg for pgsql-general@arkaria.postgresql.org; Thu, 06 Nov 2025 09:29:21 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vGwIz-006bi3-Uf for pgsql-general@lists.postgresql.org; Thu, 06 Nov 2025 09:29:21 +0000 Received: from mail-yx1-xb130.google.com ([2607:f8b0:4864:20::b130]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vGwIw-006HTO-0D for pgsql-general@postgresql.org; Thu, 06 Nov 2025 09:29:20 +0000 Received: by mail-yx1-xb130.google.com with SMTP id 956f58d0204a3-63f976ef4bdso765807d50.1 for ; Thu, 06 Nov 2025 01:29:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=percona.com; s=google; t=1762421356; x=1763026156; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JLMexhUW5oPWnOws1ex6Z+Fy6QY6t6MTl7J5HlNTjC4=; b=JS6szyrKr0Upmm7V4OvcpsWXcvBpRCJHQMS5oBhu4vlHfAbH65yF2DjCTKG+Vx66/3 sC9JnfOYmC+ZvnZcA13JohpIHB64PxqEjSHYzlnNpkY6n+gFNKPAmw3FsnVyoPajmr4c VdSt3O7UEaNlcqcNd5/K6HwnVIDU8jkLmDBZE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762421356; x=1763026156; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JLMexhUW5oPWnOws1ex6Z+Fy6QY6t6MTl7J5HlNTjC4=; b=Xyudw4u3D/9zAaikd/WShSxE7xW0BgyP9lC/HbNk0QMqpMpNhBqG8AdPlLVRYQcDIy xARqeO9erNnfddD5yk5yYN0liAMbJqYYoplBMsJBN/GNCIOZxpnUHmaTfjuGtt4SsQqx 3heIkvSaT2oGkqD032JZwvkvrkiPNQMaWY2TGU7XH1dLB9Y+IoSe1IwUnob9cOzdujCZ J7fMKtkzwTCQxk/YzYvDgCgloQxHoePwHuwmQEnvShpSbPIiEFo1m5RdJosYZImF5RSb 3+jMsE2SpATJ4VGVpEwiW8M9deOHfWZ+AKwoioqXDC+hp3PA0ap99TEFsIx34nYXAy7G 4I9A== X-Forwarded-Encrypted: i=1; AJvYcCWq+DCwNFLtKQcVKXgggFrzg6OZR4nfENIKt8xjpOheQ+sKeq7mn85Suttau0pq342Lz29JqZJtgX9V0goW@postgresql.org X-Gm-Message-State: AOJu0YwxpQSDoNP/ocIZMhJeZlUf9Dl3cP0bHalQdsu20Fr4P1xPD3ld r1dhI8XpbAWBMp17qLk3eIiewZ/8seDapvwJr6RD2kVJVJriOOv0k282jxIYrjhOYoSUDaUhgHS bBLU57iqNY3PKFmhenlGfzPb/CqeKEWSk9L3wh+M0wpGxEu3RqP6R+Nn5efGgGY0bpJKa2OSWbb FswOBE+H+9f/sUR2m512qFacxxDDTjVZoMm4+6bWyj6xsO8OTxs9x/ZM1GM0el8bvfcISSCMn2k /JcHFjM8j3c76mNIroGAJL/vx3xiKlUheiowBO8s1TRx2VKNGk= X-Gm-Gg: ASbGnctGfRiVsCUwqNlNHnB6K6VXOG3vj9ePDHf1m3u8kzMc27/prl0kXQlJieq95dO TVUbwECG3e+6cfrTBqGUL7lUUuo8KB0PlnebA2j0e9SNyyixrYdKfu3lacgH2ZuZ1mGLDBHL+IO NzvX4bukRezQr6OhI/62T914jw9i6hsWXAGVYP6KUyVn/yzvajAYYTOwhUmX7eINvuaEyXTlNjz nKPv4HO2N2iN7U/gUmUaywPXq/+lvrL7kAB9mq15sxqoJ56a8gVygsxSZBCNlMtg9iaOPIgwSfc 1I5BJdh1xxinaNGkYxY= X-Google-Smtp-Source: AGHT+IHfzlqXA0+1xsLRIJI0qGWn/WYeDNtJzwE+q9uf4/YK1IRtR/GgSYr2yTsZO2r74Ps+G/ki4Eru3rTPDLWUU7w= X-Received: by 2002:a05:690e:2447:b0:63e:2250:2210 with SMTP id 956f58d0204a3-63fd35bb549mr3914713d50.59.1762421355648; Thu, 06 Nov 2025 01:29:15 -0800 (PST) MIME-Version: 1.0 References: <3DC589BC-A5F6-49BC-BFFC-F1FCB0FF7E95@thebuild.com> In-Reply-To: From: Jan Wieremjewicz Date: Thu, 6 Nov 2025 10:29:04 +0100 X-Gm-Features: AWmQ_blN1Bo6ncs81VvyBG3rKhjzbWYPht2S2OWU9XmLYP_dS-RvLAWUTCsLdI4 Message-ID: Subject: Re: Enquiry about TDE with PgSQL To: Bruce Momjian Cc: Laurenz Albe , Kai Wagner , Chris Travers , Christophe Pettus , "Clay Jackson (cjackson)" , pgsql-general , Ron Johnson Content-Type: multipart/alternative; boundary="000000000000d9b61b0642e9b27b" X-CLOUD-SEC-AV-Sent: true X-CLOUD-SEC-AV-Info: percona,google_mail,monitor X-Gm-Spam: 0 X-Gm-Phishy: 0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000d9b61b0642e9b27b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just wanted to throw in my two cents, or actually, two points, on TDE: 1. Extensions seem like the right place for most of the TDE logic. Encryption usually depends on organization specific or even proprietary security systems. Think of features like KMS integrations th= at need custom handling and are often owned by Security, Compliance, or IT rather than DBAs, so it is hard to convince DBAs to stick to a "supporte= d" one. That kind of setup is difficult to generalize into PostgreSQL core, and extensions give the flexibility to make it work. The same goes for cloud KMS or HSM certification integrations, which add another layer of complexity that is easier to manage outside core. Also, by relying mainly on new hooks, we can keep changes to the core minimal and make TDE as non-intrusive as possible for those who do not n= eed it. 2. About the "single-vendor open source" comment... That was never the goal when we kicked off pg_tde. Sure, Percona funded the initial work, but we would really like to see this become a broader community effort. We saw a gap that enterprise users were facing and tried to fill it based on what we had learned from other databases, but the more peopl= e get involved, the better this can become. On Tue, Nov 4, 2025 at 3:06=E2=80=AFAM Bruce Momjian wro= te: > On Mon, Nov 3, 2025 at 07:42:06PM +0100, Laurenz Albe wrote: > > On Mon, 2025-11-03 at 11:56 -0500, Bruce Momjian wrote: > > > The problem with the Percona extension is it seems like it was > developed > > > mostly/all by Percona employees, meaning development was driven/steer= ed > > > by Percona, and there was insufficient feedback from the community fo= r > > > it to be polished enough to be a general community solution. > > > > Reading a Percona blog, it looks like you need a modified server to get > > to encrypt WAL, and they probably have no support for encrypting > > temporary files. So I'd say that TDE can probably not be a pure > extension. > > Perhaps somebody from Percona can confirm. > > Yes, the server has to be modified because the hooks they need don't > exist in the community source code. They also have encryption control > on the table level, which I frankly think will never work long-term > because the storage API doesn't have enough table-level detail, so I > think they are considering tablespace-level or cluster-level encryption. > > > But I don't think it's a shortage of implementations for TDE that is th= e > > problem. > > > > Since you say that encrypting the temp files is the biggest hurdle for > > community acceptance, what about a first version that does not encrypt > > temp files? For one, that will be good for encrypted backups (which is > > one of the good use cases for TDE), and then you could argue that temp > > files are not data *at rest*, so data-at-rest-encryption does not apply > > to them. Rome wasn't built in a day, and neither were parallel query > > or declarative partitioning. > > Uh, people will say that if the solution is not 100% secure in its > coverage, it is much less useful and therefore not worth it. > > -- > Bruce Momjian > https://url.avanan.click/v2/r01/___https://momjian.us___.YXAzOnBlcmNvbmE6= YTpnOjI1Nzk5MzJmMmQ0NDFlMGE0NGRhMjc4NDMwYWVkZDZlOjc6MTFhOToxZDRhZjAyODZkMjQ= 3MzlhM2EwMWUzNmFkZGM0ZTkyYmQ3MjE0NWVlY2VjZDRmYTFkMWM2NTUxOTUwYjQ1OGY5OnA6VD= pO > EDB > https://url.avanan.click/v2/r01/___https://enterprisedb.com___.YXAzOnBlcm= NvbmE6YTpnOjI1Nzk5MzJmMmQ0NDFlMGE0NGRhMjc4NDMwYWVkZDZlOjc6ZGM0YTphNjQ1MzQyO= WEyNzBiNzYyYTc5NjJlN2NlYjU1ZTM5YmZkYWZjMTYyNzViN2IzNWQzOTU4N2QxZTIwNjcxMDdl= OnA6VDpO > > Do not let urgent matters crowd out time for investment in the future. > > > --=20 Jan Wieremjewicz Sr. Product Manager, Percona jan.wieremjewicz@percona.com CET (GMT+1) Databases Run Better With Percona --000000000000d9b61b0642e9b27b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Just wanted to throw in my two ce= nts, or actually, two points, on TDE:

  1. Extensions seem like the right place for most of the TDE logic.
    Encryption usually depends on organization specific or even proprietary=C2= =A0security systems. Think of features like KMS integrations that need cust= om=C2=A0handling and are often owned by Security, Compliance, or IT rather = than DBAs,=C2=A0so it is hard to convince DBAs to stick to a "supporte= d" one.
    That kind of setup=C2=A0is difficult to generalize into Po= stgreSQL core, and extensions give the=C2=A0flexibility to make it work. Th= e same goes for cloud KMS or HSM certification=C2=A0integrations, which add= another layer of complexity that is easier to manage=C2=A0outside core. Also, by relying mainly on new hooks, we can keep changes to the=C2=A0cor= e minimal and make TDE as non-intrusive as possible for those who do not=C2= =A0need it.

  2. About the "single-vendor open source" comment...
    That was never the goal when we kicked off pg_tde. Sure, Percona funded the= =C2=A0initial work, but we would really like to see this become a broader c= ommunity=C2=A0effort.
    We saw a gap that enterprise users were facing an= d tried to fill it=C2=A0based on what we had learned from other databases, = but the more people get involved, the better this can become.

=



On Tue, Nov 4, 2025 at 3:06=E2=80= =AFAM Bruce Momjian <bruce@momjian.us> wrote:
On Mon, Nov=C2=A0 3, 2025 at 07:42:06PM +0100, Laurenz A= lbe wrote:
> On Mon, 2025-11-03 at 11:56 -0500, Bruce Momjian wrote:
> > The problem with the Percona extension is it seems like it was de= veloped
> > mostly/all by Percona employees, meaning development was driven/s= teered
> > by Percona, and there was insufficient feedback from the communit= y 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 ge= t
> to encrypt WAL, and they probably have no support for encrypting
> temporary files.=C2=A0 So I'd say that TDE can probably not be a p= ure extension.
> Perhaps somebody from Percona can confirm.

Yes, the server has to be modified because the hooks they need don't exist in the community source code.=C2=A0 They also have encryption control=
on the table level, which I frankly think will never work long-term
because the storage API doesn't have enough table-level detail, so I think they are considering tablespace-level or cluster-level encryption.
> But I don't think it's a shortage of implementations for TDE t= hat 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?=C2=A0 For one, that will be good for encrypted backups (wh= ich 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 appl= y
> to them.=C2=A0 Rome wasn't built in a day, and neither were parall= el query
> or declarative partitioning.

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

--
=C2=A0 Bruce Momjian=C2=A0 <bruce@momjian.us>=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://url.avanan.click/v2/r01/___h= ttps://momjian.us___.YXAzOnBlcmNvbmE6YTpnOjI1Nzk5MzJmMmQ0NDFlMGE0NGRhMjc4ND= MwYWVkZDZlOjc6MTFhOToxZDRhZjAyODZkMjQ3MzlhM2EwMWUzNmFkZGM0ZTkyYmQ3MjE0NWVlY= 2VjZDRmYTFkMWM2NTUxOTUwYjQ1OGY5OnA6VDpO
=C2=A0 EDB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://url.avanan.click= /v2/r01/___https://enterprisedb.com___.YXAzOnBlcmNvbmE6YTpnOjI1Nzk5MzJmMmQ0= NDFlMGE0NGRhMjc4NDMwYWVkZDZlOjc6ZGM0YTphNjQ1MzQyOWEyNzBiNzYyYTc5NjJlN2NlYjU= 1ZTM5YmZkYWZjMTYyNzViN2IzNWQzOTU4N2QxZTIwNjcxMDdlOnA6VDpO

=C2=A0 Do not let urgent matters crowd out time for investment in the futur= e.




--

Jan Wie= remjewicz
 Sr. Product Manager, Percona
jan.wieremjewicz@percona.com

=C2=A0CET (GMT+= 1)

Database= s Run Better With Percona


--000000000000d9b61b0642e9b27b--