I would like to thank everyone who attended my webinar, “No More Workarounds: Open Source PostgreSQL TDE Is Here,” on July 23, 2025. If you missed it, you can view the recording and slides. Here are the questions I had no time to answer during the live session. If you have more questions, post them in the comments!
Question: What is the recommended approach for backing up and maintaining encryption keys used by pg_tde?
Answer: pg_tde manages encryption through two key types:
- Internal table keys, which are generated per encrypted table and stored in the PGDATA/pg_tde directory. Those keys are not exposed externally.
- Principal keys, which are stored externally (locally managed key file is not recommended for production usage), using a Key Management System (KMS) such as HashiCorp Vault, OpenBao, or other KMIP-compliant services.
Principal keys should always be managed by the external KMS that handles backups. Remember, if you lose the principal key, your data is unrecoverable!
Question: Does pg_tde support encryption at the column level within PostgreSQL tables?
Answer: No, pg_tde has a different purpose and does not support column-level encryption. It offers transparent table-level encryption, meaning entire tables (including table data, indexes, TOAST tables, and temporary tables) are encrypted. Keep in mind that system catalogs and metadata remain unencrypted.
Question: When is Transparent Data Encryption (TDE) expected to be available in the PostgreSQL Community Edition?
Answer: pg_tde is and will be provided as an extension. At this time, pg_tde relies on code modifications (particularly in the storage manager and WAL layers) that are not yet part of the main PostgreSQL codebase. While patches have been submitted upstream, there is no confirmed timeline for inclusion in the official PostgreSQL Community Edition. Adoption may take several release cycles depending on review and approval processes. Keep in mind that Percona Distribution for PostgreSQL contains those patches and is completely open source and free to use. Also, migration is really straightforward.
Question: Will pg_tde be included by default in upcoming Percona PostgreSQL Kubernetes chart releases?
Answer: With the pg_tde 1.0 GA release (June 30, 2025), the extension is now included by default in the Percona Distribution for PostgreSQL and is supported in its Kubernetes Helm charts. Percona Operator for PostgreSQL can use pg_tde as an external extension as of version 2.6.0. One of the next releases will have it included within the image loaded by the Operator.
Question: Are organizations migrating databases from cloud environments back to on-premises, and how does pg_tde support this?
Answer: Yes, some organizations are migrating workloads from the cloud to on-premises environments due to regulatory, security, or cost considerations. pg_tde supports such migrations by enabling consistent encryption practices in self-managed PostgreSQL deployments.
Question: In regulated industries such as healthcare, how does encryption compare to overall database governance for HIPAA compliance?
Answer: While encryption at rest is a critical requirement for HIPAA (particularly for protecting PHI), it is not sufficient on its own. Comprehensive database governance is equally, if not more, important. This includes:
- Role-based access controls
- Strong authentication and authorization policies
- Detailed logging and auditing
- TLS for data in transit
- Defined data retention and destruction policies
Encryption (like that provided by pg_tde) should be part of a broader governance and compliance framework.
Question: Does re-encryption have performance implications for large-scale databases (e.g., in terabyte ranges)?
Answer: Yes, while pg_tde supports online encryption and key rotation, the process of re-encrypting existing tables can be resource-intensive, especially for large tables. CPU and I/O overhead can be significant depending on the workload. It’s advisable to schedule re-encryption during low-traffic periods and closely monitor performance metrics during the process. The impact is similar to rewriting the data from scratch (or in other words, executing a “CREATE TABLE AS SELECT” command. This is because the data physically stored on a disk needs to be rewritten and encrypted.
Question: How can organizations audit and verify that Transparent Data Encryption is functioning correctly, especially in large deployments?
Answer: Auditing pg_tde deployments involves several key steps:
- Validate that encrypted tables use the pg_tde access method, and, through a relevant helper function.
- Track internal key generation and usage through logs and key directories.
- Use CLI tools like pg_tde_change_key_provider to validate key rotations.
- Integrate PostgreSQL logs with external SIEM systems to track encryption-related activity.
- Confirm that backups remain encrypted and access to key files is secured.
Question: What is the expected performance impact of enabling pg_tde encryption in PostgreSQL?
Answer: 3rd party performance benchmarks have shown modest overhead, primarily in CPU usage during read/write operations. The impact is workload-dependent but generally acceptable for modern hardware. Write-heavy applications may experience a more noticeable performance change, so it’s important to benchmark in your specific environment. You can check independent tests here: https://andreas.scherbaum.la/post/2025-06-30_performance-test-for-percona-transparent-data-encryption-tde
Question: How can existing unencrypted tables be migrated to use pg_tde encryption?
Answer: Since pg_tde requires specifying the USING pg_tde access method during table creation, existing tables must be altered (and then data will be rewritten) or migrated manually:
- Create a new encrypted table using USING tde_heap.
- Copy data from the original table into the new encrypted one.
- Replace or rename the old table accordingly.
Question: Is there a roadmap for implementing full database-level encryption in pg_tde (i.e., including system catalogs and all database objects)?
Answer: Currently, pg_tde focuses on table-level encryption and encryption of the WAL. There are no immediate plans for full database-level encryption (including system catalogs and global objects).
With Percona, you can access Transparent Data Encryption (TDE) for PostgreSQL without licensing fees or usage restrictions. Additionally, you can contact Percona Experts via Support and Services to further strengthen your PostgreSQL security.
About the Author
Michal NosekAs a Senior Enterprise Architect at Percona, Michal’s objective is to bridge the gap between database technologies and business outcomes by providing customers with appropriate strategies and open-source database solutions. He works with companies on all continents. Michal holds a BS degree in Computer and Information Science from the Cracow University of Technology. He lives in Gdansk, Poland. In his spare time, Michal enjoys traveling and windsurfing.
