pg_vault_tde v1.7.1 : Transparent Data Encryption for PostgreSQL 17 and 18

pg_vault_tde 1.7.1 implements transparent data encryption for PostgreSQL 17 and 18 by introducing a new table access method called encrypted_heap. This method intercepts tuples before they reach the storage manager, encrypting them with AES-256-GCM, and decrypts them after retrieval. The implementation is designed to be transparent to applications, meaning existing queries and operations continue to work without modification. The encryption is applied at the tuple level, which provides granular protection for individual rows while maintaining compatibility with PostgreSQL's storage architecture.

Key management is handled externally to the database, supporting multiple backends including HashiCorp Vault, OpenBao, PKCS#11 tokens, HSMs, or local PKCS#12 wallets. Each table uses its own data encryption key, which can be rotated online without downtime. This separation of keys from the database reduces the risk of key exposure through database backups or unauthorized access. The requirement for PostgreSQL 17 or 18 and OpenSSL 3.x suggests the implementation relies on modern cryptographic APIs and may not be compatible with older PostgreSQL versions or alternative SSL libraries.

The 1.7.1 release fixes an issue with the additional authenticated data (AAD) derivation for out-of-line TOAST values. This change means TOAST data written by version 1.7.0 or earlier will not authenticate correctly under 1.7.1, requiring affected tables to be exported before upgrading. The documented procedure in the README provides a migration path, but this incompatibility introduces operational overhead for existing users. The fix suggests the previous implementation had a cryptographic flaw that could potentially allow tampering with TOAST data without detection.

The project is distributed under the PostgreSQL license and provides both source code and pre-built .deb and .rpm packages through GitHub and PGXN. This distribution model aligns with common PostgreSQL extension practices, making it accessible for both development and production environments. The availability of binary packages reduces the barrier to adoption for teams that may not have the resources to compile extensions from source. However, the requirement to add the library to shared_preload_libraries means administrators must restart PostgreSQL to enable the extension, which may impact service availability during deployment.