pg_tde can now encrypt your WAL on PROD!

Just recently, we announced the production-ready release of pg_tde, bringing open source Transparent Data Encryption (TDE) to PostgreSQL.
Now, I may have spoiled the fun a little with the title, but take a look at the word puzzle below—can you guess the announcement? Bear with me… and my sense of humor, which might be a bit too dry for some :)

At the time of the TDE GA release, one of the most common questions was:

“How does pg_tde handle the data in Write Ahead Logs (WAL)?”

The short answer back then was:

“It can encrypt WAL data, but the feature is still in beta.”

I’m happy to share that this capability is now production ready as well! WAL encryption has reached General Availability (GA) and is included in the latest release of Percona Distribution for PostgreSQL 17.5.3.

How to use it?

To use WAL encryption, you’ll need both:

• pg_tde extension
• Percona Server for PostgreSQL (included in Percona Distribution)

Why? Because pg_tde relies on patches that extend PostgreSQL APIs, and these are not yet available in the upstream PostgreSQL Community releases. Our long-term goal is to ensure they are available in the Community PostgreSQL Server as well, but for now you’ll find them only in Percona Server. If you’ve already been running the GA version of TDE in Percona Distribution 17.5.2, the upgrade is straightforward. Assuming pg_tde is installed and initialized, enabling WAL encryption requires:

• Configure the encryption key by:
  • Setting up the key provider for WAL encryption
  • Creating the principal key
• Turning the WAL encryption on by running:
  • ALTER SYSTEM SET pg_tde.wal_encrypt = on;
• Restarting the server to apply the changes

⠀Full step-by-step documentation is here.

Some known limitations of the first version

While WAL encryption is now GA, there are some first version limitations to be aware of:

• Compatibility with other extensions: pg_tde has only been validated with the extensions shipped in Percona Distribution. Extensions that rely heavily on WAL (such as some backup, replication, or logical decoding tools) may not yet work correctly.
• Backup and restore:
  • WAL encryption has been tested and verified with PgBackRest, our recommended tool for backup and recovery.
  • pg_basebackup works with WAL encryption when using streaming or none methods. While the -x fetch method is not yet supported for other methods there are some good practices we highly recommend.
  • Other backup tools may not yet support WAL encryption. An example is Barman as the following Barman backup methods are not yet supported with WAL encryption:
    • Postgres method
    • Rsync method
    • Snapshot method
• Native logical replication: tools like pg_createsubscriber are not yet supported with encrypted WAL. We are planning to enable them in one of the next releases. Do share feedback if you need them, it will help us prioritize.

See more details regarding the WAL encryption GA supported scope in our documentation. We’ll continue testing compatibility with widely used extensions and documenting what works out of the box versus what requires extra steps. Here, we rely on our community of users as well to let us help prioritize work. Let us know what would you want to see tested or you’ve already tested and need help in making work with WAL encryption.

Why this matters for regulated environments

STIG documentation proves that PostgreSQL is ready to tackle any government use cases already. Encryption of both data files and WAL is often a requirement when organizations work under strict compliance frameworks such as:

• FIPS 140-2 / 140-3 – cryptographic module validation requirements for U.S. government use.
• HIPAA – protection of electronic protected health information (ePHI).
• PCI-DSS – encryption requirements for cardholder data at rest.
• FedRAMP and other government security standards – full coverage of data at rest, including temporary and log files.

Many PostgreSQL distributions rely on filesystem-level encryption or external tooling to meet these standards. With PCI-DSS 4.0 this is no longer enough. With pg_tde, encryption is native to PostgreSQL internals, ****covering both tables and WAL, implemented with widely recognized cryptographic algorithms via OpenSSL, and integrated with enterprise grade Key Management Systems (KMS). This reduces operational complexity and helps align directly with compliance controls.

What does the future hold for TDE?

We’re far from done. The roadmap for TDE includes:

• New capabilities:

  • More cipher configuration options
  • Expanded KMS support (beyond what we support today)
  • Temporary files encryption
  • Features requested from real-world deployments

• Lifting current limitations:

  • Broader backup/restore scenarios
  • Compatibility with logical replication tooling such as pg_createsubscriber
  • Validating more third-party extensions

• Upstream contributions:

  • Our long-term goal is to contribute the necessary server patches into Community PostgreSQL. This way, pg_tde can eventually run on any PostgreSQL release, not just Percona Server for PostgreSQL.

We’d love your feedback! If you’ve started using pg_tde or are planning to test it (especially with WAL encryption) let us know what works well, what could be improved or fixed, and what you’d like to see next. Your input directly helps us prioritize features, improve compatibility, and shape the future of TDE in PostgreSQL.

Share your experiences via our Community Forums, alternatively via GitHub Discussions or Issues! ∎