Why and When In-Memory Encryption is Required for PostgreSQL
Disclaimer: This section was written by PostgreSQL engineers trying to interpret complex legal texts. It should not be considered legal advice. Consult qualified legal counsel for definitive compliance guidance.
TL;DR: If you’re asking whether this extension is for you, it probably isn’t
Data Encryption in PostgreSQL is a complex topic.
As of 2025, new regulations such as the Digital Operational Resilience Act (DORA) or PCI DSS 4.0 introduced significant new encryption requirements for financial entities. Unlike previous regulations that only mandated encryption of "data at rest" and "data in transit", these new standards require encryption policies to cover also "data in use".
This is a fundamental shift with major implications for database security and this PostgreSQL extension aims at offering an safe, simple and open-source solution to achieve compliance with these new regulations.
However, if the DORA and PCI DSS standards don’t apply directly to you, congratulations ! This means that Transparent Column Encryption (TCE) is probably not what you’re looking for and implementing Full-Disk Encryption (FDE) may be good enough for you.
The Three Encryption Requirements
In DORA's Regulatory Technical Standards (RTS) on ICT Risk Management, the article 6 specifies that financial entities must establish encryption policies covering:
- data at rest, which means encryption at the storage layer : disk encryption, encrypted filesystems, etc.
- data in transit, which is covered by network encryption mechanisms such as TLS/SSL
- data in use, which applies to data being actively processed in memory
DORA is not alone in requiring protection of data in memory. The Payment Card Industry Data Security Standard (PCI DSS) has recently undergone a parallel evolution.
While PCI DSS 3.2 allowed disk-level encryption as the primary method to protect card holders information, the version 4.0 explicitly prohibits using disk-level as the sole method of encryption. The requirement states that if disk encryption is used on non-removable media (servers, storage arrays), it must be combined with another mechanism such as file-level, column-level, or field-level database encryption.
What is "data in use" ?
There's is no official definition of the term "data in use" but the common acceptance is that it refers to information currently being created, updated, processed, accessed, or manipulated by a computer program.
In the context of a PostgreSQL database, this means the data loaded into the database server memory (shared buffers, work memory, etc. ).
Why the traditional "encryption at rest" approach is insufficient
Disk-level and filesystem encryption only protect information when it is stored on disk. But once PostgreSQL loads data into memory for processing, it exists in its plaintext form, creating significant vulnerabilities ( such as memory dumps ).
That's why new regulations expand their data protection requirements across the entire data lifecycle, explicitly acknowledging that sensible data remains vulnerable when it is available for processing (i.e. when it is "in use").
However both DORA and PCI DSS had nuance and précisions to that principle. For instance DORA recognize that the encryption of "data in use" should be done "where necessary" ( DORA Article 6.2 ) and PCI DSS states that organization should identify all locations where sensible data is "stored, processed, and transmitted" ( PCI DSS Requirement 12.5.1 ).
Technical Solutions for PostgreSQL
To comply with those requirements with PostgreSQL, Transparent Column Encryption (TCE) is the best approach, because :
- The sensible data is encrypted in memory
- The columns which should be protected are explicitly identified
- Encryption is not applied to the columns that don't need protection
On the contrary, Transparent Data Encryption (TDE) (also know as Cluster File Encryption) is applied for the entire Postgres instance without any distinction between sensible and regular data. The encryption/decryption often occurs during the file access method, which means data is stored in plaintext in memory.
Conclusion
DORA and PCI DSS 4.0 are significant evolutions in data protection requirements for the financial and payment sectors. The explicit inclusion of "data in use" encryption means that traditional database security approaches (disk encryption + network TLS) are no longer enough for regulatory compliance.
Organisations subject to these regulations must implement in-memory encryption technologies or provide documented risk-based justifications and equivalent protective measures to meet modern compliance requirements.
They need to acknowledge that:
- Disk encryption alone is insufficient
- Database-level encryption (TDE/TCE) is now a requirement
- Transparent Column Encryption allows to define a fine-grained policy by describing which are the sensible columns and applying encryption only where necessary.
The "data in use" requirement represents major evolution in how we protect sensitive information, it is not a temporary trend but reflects the globale evolution of industry.
References
DORA
Regulatory Technical Standards on ICT Risk Management Framework https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1774
PCI DSS
PCI DSS: Payment Card Industry Data Security Standard v4.0 https://listings.pcisecuritystandards.org/documents/PCI-DSS-v4_0-FR.pdf