"Is your data encrypted at rest?" arrives from an auditor, a customer security review, or a regulator, and it sounds like a yes-or-no question.
Postgres encryption at rest comes in several forms that protect different things at different costs. This post covers what it protects against, the options available, how they compare on coverage, and why key management usually decides the outcome.
Postgres encryption at rest comes in several forms that protect different things at different costs. This post covers what it protects against, the options available, how they compare on coverage, and why key management usually decides the outcome.
What encryption at rest protects against
Encryption at rest protects stored data from anyone who obtains the underlying files or media without valid database credentials. A stolen disk, a copied backup, a decommissioned drive, or filesystem access on a compromised host all become useless to the holder, because what they have is ciphertext. Encryption does not prevent access to the files. It denies access to the content, a narrower and more useful claim than the one usually made for it.
The limit matters as much as the protection. Encryption at rest does nothing against an attacker holding valid credentials, because the database decrypts for them exactly as it would for a legitimate user. It is a control against media compromise, not account compromise, and overstating that is the most common error on this topic.
Two things also get collapsed into one answer. Encryption at rest protects stored files, while encryption in transit protects network communications between clients and the server and between primary and standby. Most enterprise deployments require both, and an auditor asking about one will ask about the other. This article covers the at-rest half.
Why database teams end up owning encryption
Databases provide authentication and authorization to control access to the information inside them, but responsibility for protecting the physical files is often left to another team or spread across several. Storage owns the disks, platform owns the hosts, and nobody owns the gap between.
You are better off taking ownership of it. The database team is the only group that knows which tablespaces hold regulated data, where the write-ahead log is archived, and which backups leave the building.
The four places you can encrypt
Encryption options for PostgreSQL sit at four distinct layers, and they are frequently compared as though they were alternatives when they protect against different things.
Infrastructure level: full disk and filesystem encryption
Full disk encryption, typically with LUKS and the cryptsetup tooling on Linux, encrypts the block device beneath the filesystem. Everything PostgreSQL writes is covered without the database knowing anything about it, which makes this the least intrusive option to adopt.
What it protects against is physical access, such as a drive removed from a rack, a disposed disk, or a stolen laptop. Once the volume is mounted, every file is readable to any process with filesystem permission, including an attacker who has compromised the host. Backups written elsewhere are not covered unless that system is encrypted too.
Database level: Transparent Data Encryption
Transparent Data Encryption encrypts data as PostgreSQL writes it and decrypts it on read, with no change to applications or SQL. The boundary sits inside the database, so coverage follows the data rather than the volume, and a file copied off the host stays encrypted.
Community PostgreSQL has no native Transparent Data Encryption, so the options are an enterprise distribution that includes it or an extension. pg_tde from Percona is the main open source implementation, reaching general availability after a long beta, with AES-256 support and production-ready WAL encryption in later releases. It carries operational constraints worth reading first, including restrictions around pg_upgrade and the standard command-line utilities, which have pg_tde-specific equivalents. CYBERTEC takes a different route with an encryption patch shipped in its enterprise edition, encrypting at cluster level rather than per tablespace, though moving an existing cluster onto it requires a dump and reload.
Field level: pgcrypto
pgcrypto encrypts individual values, typically storing the result in a bytea column. It is the only approach here that keeps data encrypted while the database is running and the only one that can keep a value opaque to a DBA with full database access.
The cost is paid by the application, which has to encrypt on write and decrypt on read, and by the query planner, since indexing and searching on encrypted fields becomes difficult and sort order is meaningless. Our overview of pgcrypto goes through the functions in detail. Field-level encryption suits a small number of genuinely high-sensitivity columns, not a whole schema.
Managed service storage encryption
Managed PostgreSQL services such as AWS RDS encrypt storage volumes, snapshots, and backups, usually on by default with nothing to configure. For many workloads that is a reasonable baseline with no operational burden.
The question to ask is not whether the provider holds the keys, since most platforms support customer-managed keys in their own key management service and some support bringing your own key material. It is what your key custody arrangement actually is on the plan you run, who inside the provider can reach the key, and whether that satisfies the data sovereignty and residency obligations you have to evidence. Those answers vary by provider, region, and configuration, so check rather than assume in either direction.
What each option actually covers
A database file is not the only place your data lands. The write-ahead log, transaction logs, temporary files from large sorts and merges, and backups all hold the same content, and an approach covering the tablespace while leaving the WAL or backups in the clear has a gap an audit will find.
| Full disk / filesystem | Transparent data encryption | pgcrypto | Managed service storage | |
| Protected | Everything on that volume | Database files, and depending on implementation WAL, temp files, backups, archive logs | Specific column values | Volumes, snapshots, and backups on the platform |
| Left unprotected | Anything copied off the volume; readable to any process once mounted | Data in memory; anything written outside the encrypted scope | Every column you did not encrypt | Data once exported outside the platform |
| Application changes | None | None | Encrypt and decrypt in application code | None |
| Performance impact | Low with hardware acceleration | Low with hardware acceleration | Per-value cost, plus lost indexing and search | Low |
| Key custody | You, on the host or in a key manager | You, in a keystore or external key manager | You, in application configuration | Provider key service, often with customer-managed key options |
| Operational burden | Low, handled at provisioning | Moderate: keystore setup, rotation, restart handling | High, carried by the application team | Lowest |
Table: comparing full disk encryption, Transparent Data Encryption, pgcrypto, and managed service storage encryption on coverage, application impact, key custody, and operational burden.
Read the top two rows together before anything else. The coverage question decides whether an option answers your actual requirement, and the rest is implementation detail.
How Transparent Data Encryption works
Transparent Data Encryption implementations generally conform to the Advanced Encryption Standard, a symmetric block cipher standardized by the US National Institute of Standards and Technology in 2001. A block cipher applies the key and algorithm to a block of data at a time rather than one bit at a time, which is what makes it fast enough to sit in the write path of a production database.
Performance is the first objection, and hardware largely answers it. Modern Intel and AMD processors implement the AES New Instructions (AES-NI) instruction set, performing the cipher operations in silicon rather than software, which moves encryption from a measurable cost to a marginal one. If you plan to use any form of encryption, confirm your processors support it.
In the Fujitsu Enterprise Postgres implementation, encryption does not increase the size of tables, indexes, or logs, and Fujitsu's own testing puts the overhead on data access times at around 5%. Our Transparent Data Encryption white paper sets out the architecture in full.
Applying Transparent Data Encryption in practice
Setup is a configuration task rather than a project. In Fujitsu Enterprise Postgres it runs to four steps.
- Edit postgresql.conf and set keystore_location, which tells the database where to store the encryption key, and tablespace_encryption_algorithm, which specifies the cipher, for example AES256.
- Execute the SQL function pgx_set_master_key with a passphrase of your choice to create the master key. This creates the keystore file in the location set in step one.
- Restart the server so the new settings take effect, passing the keystore passphrase option so the keystore opens on restart.
- Create a tablespace and specify its physical location.
From that point, data written to and associated with that tablespace is encrypted, and the scope covers table data, indexes, temporary files, WAL, backups, and archive logs. That list is the coverage argument from earlier, answered.
How strong is the encryption?
With an encrypted tablespace, an attacker who reaches your files holds ciphertext. Brute force is effectively the only remaining avenue, testing every possible key until one works, so the defense is to make the number of possible keys impractically large.
| Key size | Number of possible combinations |
| 1-bit | 2 |
| 8-bit | 256 |
| 16-bit | 65,536 |
| 64-bit | 1.8 x 10^19 |
| 128-bit | 3.4 x 10^38 |
| 192-bit | 6.2 x 10^57 |
| 256-bit | 1.1 x 10^77 |
Table: encryption key sizes and the number of possible key combinations for each.
An 8-bit key allows 256 combinations. Many industries treat 128-bit AES as adequate, and at that size the time needed to work through the combinations with current computing exceeds the age of the earth. Fujitsu Enterprise Postgres supports 256-bit. None of which argues for relying on encryption alone, since a multi-front posture is right here and key length is not the part most likely to fail.
Key management is the part that fails an audit
Encryption strength is rarely what an auditor questions. Key custody is. A passphrase stored on the same host as the data protects against a stolen disk and very little else, because anyone who compromises the host has both halves.
Where the encryption key lives
The question to answer is who can reach the decryption key, and whether that set of people is smaller than the set who can reach the data. An external key vault or a hardware security module (HSM) holds the key outside the database host, so a host compromise does not hand over both, and it produces an access log for the key itself. Fujitsu Enterprise Postgres supports storing Transparent Data Encryption keys in cloud key management services, which also splits the DBA role from the master key administrator role. That separation of duties is frequently what a reviewer is looking for, and it appears in the controls expected in regulated environments.
Rotating keys without re-encrypting data
Rotation policy is where good intentions meet operational reality. An implementation that requires re-encrypting the entire dataset to change a key will not be rotated on the schedule the policy claims, because nobody schedules that twice. The practical difference between options is whether the master key can be changed without re-encrypting the data underneath it, which is how Fujitsu Enterprise Postgres handles it. Ask before you choose, not during your first rotation.
Also decide what happens if the key is lost, because with correctly implemented encryption the data is gone. Keystore backup and recovery belongs in the runbook alongside the database backup itself.
Choosing an approach for your estate
Four questions settle most of this, and they are the questions a security review will ask anyway. What are you protecting against? What can the application absorb? Who needs to hold the keys? What will you have to evidence?
From there:
- Choose filesystem encryption when the risk you are addressing is physical, such as drive disposal, theft, or a hosting facility you do not control, and you want coverage with no database or application change.
- Choose Transparent Data Encryption when data needs to stay encrypted in files that leave the host, including backups and archived WAL, and you want that without touching application code.
- Choose field-level encryption when a small number of columns must stay opaque even to administrators with full database access, and you can accept losing indexing and search on those columns.
- Layer multiple approaches when the data is regulated, which is most of the time. Filesystem encryption plus database-level encryption is a reasonable baseline, with field-level encryption on top for a handful of highly sensitive columns.
Layering is the honest answer because these options do not compete, and encryption does not work alone either. It protects data at rest, masking governs what a role sees, and audit logging evidences who saw what. All three appear together in our list of enterprise database features regulated industries should prioritize and in the wider security practices for enterprise PostgreSQL databases.
Fujitsu Enterprise Postgres addresses the coverage and custody gaps named above. Its Transparent Data Encryption extends to tablespaces, WAL, temporary files, backups, and archive logs rather than data files alone, it supports 256-bit encryption, and keys and data are managed separately with support for cloud key management services. Those sit alongside data masking and dedicated audit logging as one security model rather than three projects. Try transparent data encryption against your own workload with a free trial of Fujitsu Enterprise Postgres, and see what the coverage and overhead look like in your environment.
Frequently asked questions about Postgres encryption at rest
Does PostgreSQL support transparent data encryption natively?
Community PostgreSQL does not include native Transparent Data Encryption. It is available through an extension such as pg_tde, through a patched distribution, or through an enterprise distribution that builds it in.
What is the difference between Transparent Data Encryption and filesystem encryption?
Filesystem encryption protects a volume and covers everything written to it, but files are readable to any process once the volume is mounted. Transparent Data Encryption encrypts inside the database, so data stays encrypted in files copied off the host.
Does encryption at rest cover backups and transaction logs?
That depends entirely on the implementation. Some cover only data files, leaving WAL, temporary files, and backups in the clear, so confirm the scope before assuming coverage.
How much does encryption at rest affect database performance?
With AES-NI hardware acceleration the overhead is small for most workloads. Fujitsu's own testing puts Fujitsu Enterprise Postgres Transparent Data Encryption at around 5% on data access times, with no increase in the size of tables, indexes, or logs.
Where should PostgreSQL encryption keys be stored?
Anywhere other than the host holding the data. An external key vault, a hardware security module, or a cloud key management service separates key custody from data custody, which is what reviewers look for
