This fall feels like a good moment to stop and look at what’s changed in PostgreSQL security over the last months and also what you can use right now to make your PostgreSQL deployments safer.
PostgreSQL Transparent Data Encryption (TDE) from Percona
For many years, Transparent Data Encryption (TDE) was a missing piece for security serious PostgreSQL deployments. While the discussions about the open source implementations were stalled, we kept hearing from users that this was a blocker for compliance. Security and audit teams often required encryption at rest, and DBA teams had to jump through hoops to meet those requirements.
Having experienced the same with MySQL and MongoDB in the past, where the Community editions are missing these capabilities typically required in enterprise deployments, we understood very well the severity of this feature gap.
That’s why, for some time, we’ve been working on the first fully open source TDE solution for PostgreSQL. With Percona Distribution for PostgreSQL 17.5.2, this solution became production-ready. Using pg_tde by Percona together with our patched PostgreSQL server, you can finally enable native encryption of your PostgreSQL data at rest. Simply deploying the open source Percona Distribution for PostgreSQL, you can start using TDE without any closed-source components.
It’s free, open source, and we tested it with several Key Management Systems (KMS) and with the extensions already shipped in Percona Distribution for PostgreSQL.
Starting with Percona Distribution for PostgreSQL 17.5.3, we also made WAL encryption production-ready. By changing just one parameter, you can start encrypting your WAL.
This closes one of the biggest security feature gaps for PostgreSQL open source users.
Software Bills of Materials (SBOMs) from Percona
After the SolarWinds supply chain attack in 2020 and the Log4j incident in 2021, it became clear that the industry must improve visibility into the software we all run.
Software Bills of Materials (SBOMs) are quickly moving from a “nice-to-have” to a legal and compliance requirement. Regulations like:
and guidance from NIST is now influencing industry rules: healthcare (FDA), finance (PCI DSS 4.0), automotive (ISO/SAE 21434 and UN Regulation No. 155).
On top of this, new open source tools like GUAC make SBOM adoption easier and help organizations see what software they run and where the risks are.
Seeing this trend, Percona now ships SBOMs for our PostgreSQL software. This lets your security and compliance teams react faster to vulnerabilities, improve incident response, and meet regulatory requirements with less manual work.
Stay on the latest minor version to keep the CVEs away
Known CVEs are a real risk, and they should not be ignored. The PostgreSQL Community does an excellent job fixing vulnerabilities quickly, but you still need to deploy those fixes.
For example, the 17.6 release addressed six CVEs. By using Percona Distribution for PostgreSQL 17.6.1, you get all those fixes plus the newest TDE and WAL encryption improvements.
Regular upgrades are the simplest way to keep your database secure. In case you’re interested to see how many CVE’s your deployed versions has unaddressed, you can use this online tool (kudos to Depesz).
PostgreSQL 18 is coming to remove security headaches for DBAs
PostgreSQL 18 is almost here. RC1 was just released last week, and it brings several security improvements DBAs have been waiting for.
Goodbye MD5
MD5 authentication is deprecated. For years, DBAs had to manually disable MD5 and enforce stronger authentication to pass audits. This was painful and easy to get wrong. Now PostgreSQL makes this more secure by default: fewer manual steps, lower maintenance cost, and fewer audit headaches.
Hello OAuth 2.0
PostgreSQL 18 now supports OAuth 2.0 authentication natively. This means it will be now possible to connect PostgreSQL directly to your enterprise SSO provider (Okta, Azure AD, etc.).
For security teams, this means centralized user management and MFA enforcement. For DBAs, it means fewer custom scripts and less time spent managing users manually.
Defaulting to Data Checksums
initdb now enables data checksums automatically. This new default makes it easier to detect corruption early and reduce the risk of unnoticed data tampering without extra configuration required. By ensuring data integrity, security is enhanced as it’s one less attack vector to be exploited in attacks.
OIDC is coming soon
While OAuth 2.0 is now supported, native OIDC is still being developed.
Work is ongoing, and we are listening to users asking for it. Expect updates soon. We are committed to helping drive this forward.
What’s next?
TDE will keep evolving. Expect more configuration options and features in the near future coming to pg_tde by Percona. We also keep working with the PostgreSQL Community to eventually bring TDE required extensibility into PostgreSQL core.
Beyond encryption, we are planning more improvements around monitoring and auditing. Secure database operations are about visibility too!
We want your feedback. Tell us what is missing, what security pain points you face, and what you want us to solve next on the forums, GitHub, or even directly.
About the Author
Jan WieremjewiczJan is a Senior Product Manager at Percona, leading the products for PostgreSQL. He has vast experience in the development, deployment and maintenance of enterprise systems. Professionally, he is passionate about simple solutions that solve complicated problems and user experience that maximizes the product potential. Privately he is a foodie by day, a tech geek into graphic novels, video and board games by night and parent/spouse in between. Having spent already almost two years in Percona, most of us learned that he has enough energy and topics to fill in any space and time.
