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 1vEvMg-003mCI-5G for pgsql-general@arkaria.postgresql.org; Fri, 31 Oct 2025 20:04:49 +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 1vEvMf-000JKZ-4X for pgsql-general@arkaria.postgresql.org; Fri, 31 Oct 2025 20:04:48 +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 1vEvMe-000JKO-O9 for pgsql-general@lists.postgresql.org; Fri, 31 Oct 2025 20:04:47 +0000 Received: from mail-qt1-x835.google.com ([2607:f8b0:4864:20::835]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vEvMb-005IsD-0g for pgsql-general@postgresql.org; Fri, 31 Oct 2025 20:04:47 +0000 Received: by mail-qt1-x835.google.com with SMTP id d75a77b69052e-4ed0d2a949dso19871891cf.1 for ; Fri, 31 Oct 2025 13:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=percona.com; s=google; t=1761941083; x=1762545883; 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=hITzCFqY3osxvfZQWe1JuA3fbhteFNNzn/2XR87qZMc=; b=Q0A5txuDVrFPrThrNJu0FHT1BDhk0cXyzV8F9zSW1hNtvwIEtCVmuEU2GEjkOW+LBW kXMs/AbwhIj7I7rmcMP46Gu6+1oKBsGrWNaQxxjXwFv9kmW2tZAkIy8GvCUzGOufQ7Wp VtZ7tYzwQzEDF2rjGvymRAn+KEXOm2/hwT0Bc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761941083; x=1762545883; 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=hITzCFqY3osxvfZQWe1JuA3fbhteFNNzn/2XR87qZMc=; b=M44vRNCGmr09EINDwNbPfbjp2H3LNXVFj46d9UbFeS/LeNJAJQJt3UCvyUt1kEI3q3 CjaT5TvNo0vSvxzoSRDk+cAw+WUfHNbnBXJVVF5uCf/fh/3prJQbVkpqvBb/5iSU9PEC euJyc5Vyr+q7GFlll7vAg5jL60UzoWVJNCTkRUMnI5qWYEEAK0kmdqHYT6bBPovIPmLe /WfXR69UbN54yxl8nFI6f8i/JlgXV8+czn4mDGA2CJxVk16CVwHjWlQWDx7t4gCKufA1 9Fpndf1RSJ1AoX8Dep+/Zo2xj0k+8mfrK2PrrTXo42iNywB4xLS/NiRJB9H28zvvN3xY 5y6Q== X-Forwarded-Encrypted: i=1; AJvYcCX52EdoT3PD/iGzezUWGofVWTES0KnFutVVE5u85VWmmUAHmnOkUvqtiiNAQ8dcSllIl5bDYPII8qCyveBI@postgresql.org X-Gm-Message-State: AOJu0YzrNypyw4yEIVqewcbXxZm41+v7alt6E1Yles4Wm5807YmjN8sB xml1qPCpqCLtdTUipgBJ32yT7NxSzvcRP/BPgknLcL4oODusyFxlly0auqiVvRNmBrC0BwVbtjl +kfIqyx+lmC9g9ScivmVKHEJ5fPwERmJ5Ecqp+HHhqe/WkeMOS5GToaHQT0yATlb/adZmb5cUzP Oq4b2TWC4rthAcyX+9My0L4iHoyAZXoeQph7EnLqo5tQIkZWqTAtwxZaipRBpmpOSNNdxoiNZoU 4bisaNMWzTDdUTa6obCG2UI8fpUlPZzgQ2bb4XLzA/CfdZa5aY= X-Gm-Gg: ASbGnct4Z2jQwu39rfDYPEfe+ENouMYsDsGtM2c/t0b8RR0dEO9mrQbUu4b9esTRAww pBJD2J0EQliFkllSQ0Mn0IFLTR31rAzyix+xCm3UzKyyW4IOJ3zW4VBY2Or7oMOT30BGbFUiZYv HLuJX0F3rNR0PDHHunszQIOTn5Kh+EqaPcbjuNITu9s8ggTnQ7RH4QlotBfNly1SNnWmUKiMbE9 WmJPHy9u9j484Nv32E90SvgK08afO20U2tSImOArLgnOhyNpE0TAaMQn/j2mQ== X-Google-Smtp-Source: AGHT+IE7EYWOo1OZjTBlzrLU7uyWM12aheeg5cep5d6HMIp3NQGIej79dIB2l+J5LwkTwXTBU/jk1o9i62DcRY2ucxU= X-Received: by 2002:a05:622a:1105:b0:4e8:bbd4:99ea with SMTP id d75a77b69052e-4ed30fd4c00mr65078161cf.44.1761941083050; Fri, 31 Oct 2025 13:04:43 -0700 (PDT) MIME-Version: 1.0 References: <202510311727.f5ifxfb6ufgd@alvherre.pgsql> In-Reply-To: From: Kai Wagner Date: Fri, 31 Oct 2025 21:04:32 +0100 X-Gm-Features: AWmQ_bmFKh1uoR91sudKEYAPFVKqSh2M_ctIfs7y1ICtKOsvvVl-y0Zg1CRVOfk Message-ID: Subject: Re: Enquiry about TDE with PgSQL To: Bruce Momjian Cc: =?UTF-8?Q?=C3=81lvaro_Herrera?= , Christophe Pettus , Adrian Klaver , Laurenz Albe , Ron Johnson , pgsql-general Content-Type: multipart/alternative; boundary="0000000000005eea96064279e0b7" 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 --0000000000005eea96064279e0b7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 31, 2025 at 7:22=E2=80=AFPM Bruce Momjian wr= ote: > On Fri, Oct 31, 2025 at 06:33:54PM +0100, =C3=81lvaro Herrera wrote: > > On 2025-Oct-31, Bruce Momjian wrote: > > > > > 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. > I think this assumption can be considered a false positive. The main reason this hasn't surfaced yet is that it first takes some time to adjust, and more importantly, there are the downstream forks with the necessary changes that are already in use or continue to be sold. So why stop doing this? > > > > Maybe, but I think the only reason for this is that some companies are > > implementing it locally in their forks or whatever. I bet there are > > many prospective customers that we (the open source Postgres project) > > are not reaching because of lack of certifiability in this area. > > > > Can we continue to ignore it? My impression is that that strategy will > > continue to work, perhaps indefinitely. Is it a good idea? Of that I > > am not so sure. > > Agreed. Just to state the obvious, I have never heard of any Postgres > support company discouraging the community from implementing TDE. In > fact, I have heard them strongly encourage it. > I don't think, as stated initially, that we can continue to ignore this any longer. As a project, we are losing out on a significant number of users who are willing to use fully open-source solutions, but are held back due to this requirement. We had numerous conversations over the last few years, exactly about this fact, and people went with MySQL, Mongo, or others - not because of "does this technically make sense to us as engineers, but because they couldn't fulfill their internal requirements". As Laurenz already stated very well: "rational arguments are missing the point". It's not news that we also tried a way of implementing it. What I would like to achieve here is a group of interested people who can actually make a call on how this is envisioned to work. Do we handle everything in core directly, or do we make all necessary parts extensible? This approach may be more efficient in the long run, as it also enables a variety of other use cases. This is the conversation I would like to have. We're absolutely happy and willing to spend as much time as needed to implement a solution that works directly with PostgreSQL, so we no longer ignore huge parts of the industry, which will only get worse over the next few years, as more and more standards are to follow. Once we lose this user base, we all know how long it will take to regain any of them. I don't think we want, nor should we, to go down that route, as it would harm us as a project in the long run. We have been on a rise for many years, but if we want to stay there and continue to do so, some "checkbox" or "security requirements" need to be implemented, despite "technical arguments," as otherwise some of the largest companies worldwide cannot consider using postgres. > > -- > Bruce Momjian > https://url.avanan.click/v2/r01/___https://momjian.us___.YXAzOnBlcmNvbmE6= YTpnOmEyOTY2NTBjZWViOWUxZGMyMWI2ZDQwNGQ2NjZjNWQ1Ojc6MGE3MDo5YjgwNjIzYzk1NzI= 1OGRhZmNiYjJmYjFjNjI4NjFmOTI2NDM0YzM3Y2NhODZmNDE2YmEyY2UyMmM4ZDkxY2FmOnA6VD= pO > EDB > https://url.avanan.click/v2/r01/___https://enterprisedb.com___.YXAzOnBlcm= NvbmE6YTpnOmEyOTY2NTBjZWViOWUxZGMyMWI2ZDQwNGQ2NjZjNWQ1Ojc6NWUxZDo5Y2FiZWYwN= zc1YzlhNTY0MGY2ZGM0MjNmMWNjMTY1ZmJlZGNlNmZlMmI4ZjE2ZGY2Y2RmYWEwZjM5NTUzYjY4= OnA6VDpO > > Do not let urgent matters crowd out time for investment in the future. > --0000000000005eea96064279e0b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Oct 31, 2025 at 7:22=E2=80=AFPM B= ruce Momjian <bruce@momjian.us&g= t; wrote:
On Fri, Oct 31, 2025 at 06:33:54PM += 0100, =C3=81lvaro Herrera wrote:
> On 2025-Oct-31, Bruce Momjian wrote:
>
> > Yes, we have been avoiding the masquerade for years.=C2=A0 The qu= estion is
> > can we continue.=C2=A0 From the lack of discussion since April 1,= 2025, it
> > seems the answer is yes.
I think this assump= tion can be considered a false positive. The main reason this hasn't su= rfaced yet is that it first takes some time to adjust, and more importantly= , there are the downstream forks with the necessary changes that are alread= y in use or continue to be sold. So why stop doing this?
>
> Maybe, but I think the only reason for this is that some companies are=
> implementing it locally in their forks or whatever.=C2=A0 I bet there = are
> many prospective customers that we (the open source Postgres project)<= br> > are not reaching because of lack of certifiability in this area.
>
> Can we continue to ignore it?=C2=A0 My impression is that that strateg= y will
> continue to work, perhaps indefinitely.=C2=A0 Is it a good idea?=C2=A0= Of that I
> am not so sure.

Agreed.=C2=A0 Just to state the obvious, I have never heard of any Postgres=
support company discouraging the community from implementing TDE.=C2=A0 In<= br> fact, I have heard them strongly encourage it.
I don&#= 39;t think, as stated initially, that we can continue to ignore this any lo= nger. As a project, we are losing out on a significant number of users who = are willing to use fully open-source solutions, but are held back due to th= is requirement. We had numerous conversations over the last few years, exac= tly about this fact, and people went with MySQL, Mongo, or others - not bec= ause of "does this technically make sense to us as engineers, but beca= use they couldn't fulfill their internal requirements". As Laurenz= already stated very well: "rational arguments are missing the point&q= uot;.

It's not news that we also tried a way o= f implementing it. What I would like to achieve here is a group of interest= ed people who can actually make a call on how this is envisioned to work.= =C2=A0Do we handle everything in core directly, or do we make all necessary= parts extensible? This approach may be more efficient in the long run, as = it also enables a variety of other use cases.=C2=A0This is the conversation= I would like to have. We're absolutely happy and willing to spend as m= uch time as needed to implement a solution that works directly with Postgre= SQL, so we no longer ignore huge parts of the industry, which will only get= worse over the next few=C2=A0years, as more and more standards are to foll= ow. Once we lose this user base, we all know how long it will take to regai= n any of them.=C2=A0I don't think we want, nor should we, to go down th= at route, as it would harm us as a project in the long run. We have been on= a rise for many years, but if we want to stay there and continue to do so,= some "checkbox" or "security requirements" need to be = implemented, despite "technical arguments," as otherwise some of = the largest companies worldwide cannot consider using postgres.=C2=A0
=

--
=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___.YXAzOnBlcmNvbmE6YTpnOmEyOTY2NTBjZWViOWUxZGMyMWI2ZDQwNG= Q2NjZjNWQ1Ojc6MGE3MDo5YjgwNjIzYzk1NzI1OGRhZmNiYjJmYjFjNjI4NjFmOTI2NDM0YzM3Y= 2NhODZmNDE2YmEyY2UyMmM4ZDkxY2FmOnA6VDpO
=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___.YXAzOnBlcmNvbmE6YTpnOmEyOTY2NTBjZWVi= OWUxZGMyMWI2ZDQwNGQ2NjZjNWQ1Ojc6NWUxZDo5Y2FiZWYwNzc1YzlhNTY0MGY2ZGM0MjNmMWN= jMTY1ZmJlZGNlNmZlMmI4ZjE2ZGY2Y2RmYWEwZjM5NTUzYjY4OnA6VDpO

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