Why Postgres Lacks Transparent Data Encryption<br>Blog Home<br>Why Postgres Lacks Transparent Data Encryption
Shaun Thomas|May 22, 2026
If you've ever compared database feature matrices, you may have noticed something a bit peculiar. Oracle has Transparent Data Encryption. SQL Server has it. MySQL has it. Even MariaDB has it. But Postgres, which we all consider the best database engine? Conspicuously absent.<br>It’s not that nobody wants TDE. Compliance frameworks like PCI DSS and HIPAA practically demand encryption at rest. Cloud deployments make the “stolen disk” threat model more tangible than ever. And the question comes up constantly on mailing lists, at conferences, and in every database evaluation checklist ever assembled by a procurement department. So what gives?<br>It’s complicated. The real answer involves nearly a decade of mailing list threads, competing proposals, fundamental disagreements about threat models, and a problem scope so vast it makes most contributors quietly back away. Let’s trace the history and find out why the elephant in the room is still unencrypted.<br>The Grand Promise of TDE<br>The concept of TDE is straightforward: encrypt all data when it’s written to disk, decrypt it when it’s read back into memory. The “transparent” part means the encryption layer sits below the SQL engine so client applications operate normally without special tooling or requirements.<br>TDE protects against an attacker who gains read access to the physical storage: a stolen or improperly decommissioned drive, a backup tape that fell off a truck, or perhaps a misconfigured cloud storage volume. TDE does not protect against a compromised application, a malicious DBA, those with superuser privileges, or SQL injection. The contents of the database can be fully decrypted while the server is running, which means anyone who can connect and query can read everything.<br>This is the crux of a debate that has raged in the Postgres community for years. If TDE only protects against disk theft, and filesystem encryption (LUKS, ZFS native encryption, dm-crypt) already does the same thing, why should Postgres spend enormous engineering effort to reinvent it inside the database?<br>The answers, depending on who you ask, include:<br>Compliance checkboxes are a real business requirement.
It’s genuinely more convenient to manage encryption at the database layer.
Doing so is a waste of time; just use LUKS.
These three positions play out repeatedly.<br>Four Forks in Search of a Standard<br>Perhaps in an effort to circumvent the ongoing debate, five separate companies have independently invented TDE for Postgres, each using its own particular approach. And of course, not a single one of them is compatible with the community release, and most are proprietary. One of these (Crunchy Hardened PostgreSQL) appears to no longer exist, bringing the list down to four.<br>Here’s what remains:<br>Percona’s pg_tde is the only open-source option, but its full capabilities (index encryption, complete WAL encryption) require Percona Server for PostgreSQL, their custom fork. It uses a two-tier key architecture with AES-256-CBC for data and AES-256-CTR for WAL, and supports external key management through HashiCorp Vault and KMIP. Temporary files remain unencrypted, which is a notable gap for result sets that spill to disk.<br>EnterpriseDB offers TDE in their proprietary EDB Postgres Advanced Server from version 15 onward. Their implementation is arguably the most thorough, encrypting data files (AES-XTS), WAL (AES-CTR), and temporary files (AES-CBC). The catch, beyond requiring their proprietary server, is that TDE must be enabled at initdb time. It’s not possible to retrofit encryption onto an existing cluster.<br>CyberTec includes TDE in their PostgreSQL Enterprise Edition (PGEE). Their approach encrypts the entire cluster using AES-CTR with no option for selective per-table encryption. It’s all or nothing. CyberTec has been vocal about their TDE work influencing subsequent community discussions, and their original implementation dates back to around Postgres 12.<br>Fujitsu bundles TDE in their Enterprise Postgres product, using hardware-accelerated AES-256 with FIPS 140-2 compliance. Their approach encrypts at the tablespace level, meaning encrypted and unencrypted tablespaces can coexist. It’s a pragmatic design, but documentation is largely confined to whitepapers and sales materials.<br>Five companies, four remaining implementations, zero availability in community PostgreSQL. That should illustrate the difficulty of getting this feature into core. It’s not a lack of motivation or engineering talent. Every one of these companies did the work to make TDE a reality in their flavor of Postgres.<br>“What Threats Do You Want to Defend Against?”<br>The most instructive chapter in this saga began in May 2018, when Insung Moon from NTT proposed a comprehensive TDE design on the pgsql-hackers mailing list. The proposal was ambitious: per-table encryption granularity, a two-tier key management...