Coming to PostgreSQL: On-disk database encryption
- Reference: 1751452327
- News link: https://www.theregister.co.uk/2025/07/02/postgresql_ondisk_database_encryption/
- Source link:
So claims Percona, an open source database support and services company, which has sought to rectify the situation with its Transparent Data Encryption (TDE) extension for Percona for PostgreSQL.
Currently, the pg_tde extension is part of the open source Percona Distribution for PostgreSQL. It is compatible with PostgreSQL, available under the OSI-approved PostgreSQL License, and managed by the PostgreSQL Global Development Group.
[2]
Percona was working toward including the extension in the main PostgreSQL distribution soon, CTO Liz Warner told The Register .
[3]
[4]
"We've done some work, so it's available right now in Percona Server for PostgreSQL," she said. "It's not available in upstream vanilla PostgreSQL because that will take some collaboration with the community. We have to make some foundational changes, but we're doing the work for that. A piece of it is already in review. Ultimately, we want the TDE to be fully available to the community."
[5]A year on, Valkey charts path to v9 after break from Redis
[6]30 years of MySQL, the database that changed the world
[7]Redis 'returns' to open source with AGPL license
[8]FaunaDB shuts down but hints at open source future
Percona said it would help customers comply with policies and regulations that require encryption, such as Europe's General Data Protection Regulation (GDPR), which requires organizations to implement appropriate security measures where storage encryption alone is no longer sufficient to protect personal data at rest.
EDB, a PostgreSQL support and service provider, also provides TDE, although its extension is only available in its licensed EDB Postgres Advanced Server and EDB Postgres Extended Server [9]with the EDB Standard Plan .
"With the launch of TDE for PostgreSQL, Percona is leveling the playing field – giving every business access to enterprise-grade data-at-rest protection without licensing fees or restrictions," Warner said.
[10]
The TDE extension would encrypt all database files on disk, ensuring sensitive information remains secure even if storage is compromised, Percona said. It also offers centralized Key Management with integrations to leading Key Management Services (KMS) providers such as HashiCorp, Thales, Fortanix, and OpenBao. ®
Get our [11]Tech Resources
[1] https://survey.stackoverflow.co/2024/technology#most-popular-technologies-database-prof
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aGVXlwVPpv6fX1smUKw5AwAAAoA&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aGVXlwVPpv6fX1smUKw5AwAAAoA&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aGVXlwVPpv6fX1smUKw5AwAAAoA&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://www.theregister.com/2025/05/15/a_year_of_valkey/
[6] https://www.theregister.com/2025/05/06/30_years_mysql/
[7] https://www.theregister.com/2025/05/01/redis_returns_to_open_source/
[8] https://www.theregister.com/2025/03/24/faunadb_shut_down/
[9] https://www.enterprisedb.com/blog/everything-need-know-postgres-data-encryption?lang=en
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aGVXlwVPpv6fX1smUKw5AwAAAoA&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[11] https://whitepapers.theregister.com/
why?
HDD & SDD already encrypt. Linux already has encrypted filesystems. How does this improve anything?
Re: why?
I'm way out of my area here but it seems like an appropriate step to me when considering the cloud environment. Since these systems are accessed online, there's no such thing as an HDD or SDD in the physical sense. If I get access to your server, I'm seeing every file there, regardless of whatever encryption you've added to it. This seems like it may help in those scenarios. If I access your server online, I still can't do anything with the files because they're separately encrypted from the storage medium. At least that's what this sounds like to me. Does the Linux encryption support this kind of scenario already as well? Or am I misunderstanding things?
Re: why?
Every cloud thing is encrypted out of an abundance of fear. Considering AWS, where most of my experience is, you have the option of either using the default account key or your own per-instance KMS key for disk (ref: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html). The caveat here is that if someone gets access to your whole account, through IAM credential compromise or IAM permission stupidity, then they can access your data - just like if they root your box through SQL injection.
EC2 instances, in particular, are virtual machines. You can format virtual disks as you would any disk, use any filesystem (ext4, btrfs, zfs) that you like, and enable any (additional) encryption that you would like. RDS (managed database without a virtual machine) instances have a separate encryption flag to use your own key for at-rest encryption - but as always with anything aws, your data is never clear-text on disk.
All of this "extra" encryption is just multi-layer encryption - physical disk, logical disk, filesystem, now application layer - where no single layer of modern encryption has been compromised. Permissions, maybe - but it's usually the application layer that is compromised by external bugs, which fells all higher layers all at once. (Application layer and probably filesystem-layer encryption might save you if you set your permissions badly, where probably virtual-layer encryption will not.) All of the additional layers of encryption is yet-more compute overhead for data use -- power, latency, compute. (FWIW, modern encryption processing gets to - I read recently - 0.16 cycles per byte, with AVX-512 parallelization of PCLMUL(??) instructions.)
Re: why?
one advantage of this might be if you don't want to encrypt EBS volumes and use the native db encryption instead, this means the machine and disk are easier to image and copy to other regions or attaching the volume to another instance for recoverability is easier ? but in general most would enable the default settings of encrypting EBS volumes or equivalent in Azure. Has the disadvantage though it would offload encryption to the instance CPU's rather than let if offload ot dedicated hardware.
Re: why?
Two alternative answers.
1. Without seeing the exact details I suspect this encryption includes everything between the client and the storage medium. If that's the case it provided protection over and above what the network may already provide (on-prem that might well be nothing) so that it can't be observed by an eavesdropper or queried by anyone without an encryption key.
2. The cynical answer: it ticks another box on the ISO9000 inspired checklist.
Re: why?
HDD & SDD already encrypt. Linux already has encrypted filesystems. How does this improve anything?
An encrypted file system helps if someone steals the disks it does not help if the operating system is compromised - ie someone breaks in - to a process running under the operating system the file systems will be seen unencrypted.
Re: why?
A database will read & write a lot more than most applications so I suppose there is potential that built-in encryption yields better performance than what you get from an encrypted volume. Or perhaps people only want a particular table, or field encrypted instead of absolutely everything.
But then again maybe not. If the entire DB is encrypted then I don't think it would benefit performance to have postgres do the encryption. I think if individual tables / fields were encrypted then it might but there would are all kinds of weird corner cases to think about, like full text search, GIN indexing and other weirdness.
Marketing?
> where storage encryption alone is no longer sufficient to protect personal data at rest.
From what marketing department did this drivel originate?
Re: Marketing?
From what marketing department did this drivel originate?
Politicians.
And then just patch me till I can get my...
Another week, another compliance-driven patch to a system not built for the modern surveillance-and-regulation nightmare we now call IT.
GDPR says "encrypt it." Security says "air gap it." Finance says "cloud it." Legal says "access it." And Postgres is just trying not to segfault.