Back in October, before PGConf.EU, I explained the issues impacting the prolonged wait for TDE in PostgreSQL 18. Explanations were needed as users were buzzing with anticipation, and they deserved to understand what caused the delays and what the roadmap looked like. In that blog post I have shared that due to one of the features newly added in 18.0, the Asynchronous IO (AIO), we have decided to give ourselves time until 18.1 has been released to provide a build with TDE. We wanted to ensure best quality of the solution and that takes time.

As planned in the PostgreSQL Development Group (PGDG) roadmap, on November 13, the Community released PostgreSQL 18.1, and Percona engineers managed not only to deliver TDE compatible with the PostgreSQL 18 changes, but to fully support them. We are also skipping PostgreSQL 18.0 entirely in our distribution. The first TDE enabled release will be Percona Distribution for PostgreSQL 18.1.1, aligning our builds directly with the first PostgreSQL 18 minor release. Here are some details on what’s new!

Percona PostgreSQL + TDE + AIO

Today, we’re proud to announce that Percona now ships PostgreSQL 18.1 with fully supported TDE and AIO from the very beginning.

No patching, no workarounds, no “experimental caveats.” Encryption-at-rest is not just compatible with AIO. It’s supported, integrated and ready for production deployments across the ecosystem, enabling hardened PostgreSQL environments to meet compliance requirements with confidence as beginning with PostgreSQL 18.1, Percona:

• fully supports native TDE
• ships AIO-enabled builds, aligned with Community PostgreSQL
• provides production-ready packages for enterprise deployments

TDE matures and pg_tde returns home In 2026 we are planning significant investment to ensure that TDE continues to evolve for Community PostgreSQL. As part of this renewed focus, Percona is shifting pg_tde back to its dedicated home:

➡️ https://github.com/percona/pg_tde

This reflects pg_tde’s new role. With the growing number of pg_tde users, it can no longer be treated as a stopgap solution filling a gap in PostgreSQL. Instead, we want to approach it as a complementary, advanced encryption layer for the PostgreSQL 18+ era:

• a place to deliver extended capabilities for data-at-rest encryption as soon as they are ready
• a hub for integrations requested by the community
• a safe space for feedback, comments, and questions to help drive the future of TDE

Releasing this new version brings some real improvements, especially on the KMS integration side.

KMS improvements

We expanded Key Management Service (KMS) capabilities based directly on user and customer feedback. Whether it came through GitHub, Percona Community Forums, events, or direct conversations — thank you! Your input shapes the roadmap.

pg_tde now works with Akeyless KMS

Akeyless is gaining traction among organizations implementing zero-trust security models. pg_tde now integrates cleanly with Akeyless, enabling robust key retrieval and lifecycle management across cloud and on-prem deployments using KMIP.

HashiCorp Vault & OpenBao Namespace Support

Vault and OpenBao users can now take advantage of namespaces when storing encryption keys

Why do namespaces matter?

• Multi-tenancy: isolate key access for teams, environments, or applications
• Security boundaries: each namespace can enforce its own authentication and audit policies
• Cleaner CI/CD: dev/staging/prod can share a consistent key path structure
• Delegation & separation of duties: security teams manage root policies, while application teams manage their own namespaces

In large organizations, namespace support isn’t just a convenience, it’s a requirement. OpenBao prioritized this early and released it back in May 2025. With pg_tde now supporting namespaces natively, PostgreSQL deployments gain enterprise-grade key management flexibility.

What Comes Next?

Our commitment remains unchanged: TDE must be a first-class, accessible, community-driven feature in PostgreSQL. Share your feedback and let us achieve this! We can build the future of an open source TDE solution for PostgreSQL together with full openness and transparency!

Winter may be coming, but no weather can stop us! Expect more from TDE soon:

• Key length configurations are coming - expect to be able to use 256-bit keys with TDE soon!
• extended KMS integrations - we’re already looking into cloud KMS support. Please share which ones you are using and what use cases you want supported!
• improvements to pg_tde encryption targets - temporary files are next to be explored followed by system catalog
• compatibility with Community PostgreSQL - we want to drive inclusion of any changes required by pg_tde in Community PostgreSQL so that the extension can run for users of all PostgreSQL builds!

⠀At the risk of repeating myself, the deserved highlight goes to the fact that we build based on your feedback, so don’t be strangers!

We Want to Hear from You

Tell us how you’re using PostgreSQL with TDE. Tell us what your security requirements look like. Tell us where tooling can be improved. You can reach us at:

• Percona Community Forums
https://forums.percona.com/c/postgresql/25
• pg_tde GitHub Repo
https://github.com/percona/pg_tde
• Issues & Discussions
  • https://github.com/percona/pg_tde/issues
  • https://github.com/percona/pg_tde/discussions

Or, if you see us at an event, come chat with us in person! ∎