Product · Open-source PostgreSQL extension

pg_vault_tde

Transparent Data Encryption (TDE) for PostgreSQL

PostgreSQL doesn't include a native Transparent Data Encryption feature. pg_vault_tde encrypts table data at rest — on disk, in backups, in logical replication streams — without changing application queries and without patching the PostgreSQL core. It installs as an ordinary extension, integrates with the key management system you already use (HashiCorp Vault/OpenBao, local wallet, or HSM), and lets you rotate keys online, with no downtime.

Support and adoption: MirCrypt Request a technical assessment
Datasheet

At a glance

Product pg_vault_tde
Category PostgreSQL extension — Transparent Data Encryption (TDE)
Current version 1.7
Author Miriade S.r.l.
License PostgreSQL License (BSD 2-Clause) — permissive, compatible with MIT/BSD/ISC/Apache 2.0; no GPL/AGPL code
Supported PostgreSQL 17, 18 (PostgreSQL 19 support on roadmap)
CPU architectures x86-64, AArch64 (ARM64)
Hardware acceleration AES-NI, VAES+AVX2 (x86-64); ARM Crypto Extensions
Packaging .deb (Ubuntu 22.04/24.04, Debian 11/12), .rpm (Rocky/AlmaLinux 8/9), container image
Dependencies OpenSSL 3.x, libcurl
Installation shared_preload_libraries + CREATE EXTENSION — no recompilation or core patching
Maturity 7 incremental releases (v1.0 → v1.7); 130+ automated regression tests; zero compiler warnings on PG 17 and 18
The problem

PostgreSQL has no native TDE

Regulated organizations must prove that sensitive data is unreadable to anyone who accesses storage directly — a stolen disk, an unencrypted backup, a cloud snapshot. Without native TDE, teams have so far had three unsatisfactory options:

Disk / filesystem encryption

Protects against a stolen disk, but not against anyone who already has OS access, and protects nothing while the database is running.

Application-level (column) encryption

Secure, but it requires invasive application rewrites, breaks indexing and queries, and pushes key management into every application.

Core fork or patch

Powerful, but every upgrade requires a new patch, security backports arrive late, and you lose access to standard support channels.

pg_vault_tde bridges the gap using PostgreSQL's public Table Access Method and Index Access Method APIs (exposed from version 12 onward): SQL-transparent encryption, no application changes, none of the maintenance burden of a fork.

How it works

SQL-transparent, keys kept separate from data

Encrypted tables

Tables are created with USING encrypted_heap: each row is encrypted before it touches the disk and transparently decrypted on an ordinary SELECT. No query rewrites.

Two-level key hierarchy

A Data Encryption Key (AES-256, per table) encrypts the data; a Key Encryption Key held in your KMS wraps it. Only the wrapped key is stored in the database.

The master key never leaves the KMS

A stolen disk, a snapshot, or a pg_basebackup contain only ciphertext and wrapped keys: useless without separate KMS access.

Authenticated encryption (AEAD)

If the ciphertext is altered, PostgreSQL raises an explicit error instead of silently returning tampered or corrupted data.

Key features

What it offers

Encryption engine

Authenticated AES-256-GCM on every row via OpenSSL 3.x, with tamper detection and per-table cryptographic binding. All through the public APIs, with no core patching.

Flexible key management

KMS selectable per individual database: HashiCorp Vault/OpenBao, local wallet, or HSM (PKCS#11). Different tenants on the same cluster can use different backends.

Online key rotation

Rotation of the data key and the master key on live production traffic, with no downtime and no full table rewrite. Progress trackable in real time.

Encrypted indexes

tde_btree: a B-tree index on encrypted columns for equality lookups, with misuse-resistant deterministic encryption (AES-256-SIV).

Logical replication & backup

Output plugin for standard logical replication; dedicated pg_dump_tde / pg_restore_tde tools and authenticated key sealing (HMAC) for physical backups.

Audit & performance

Always-on, structured audit logging (KMS authentication, key rotation, denied access); hardware acceleration (AES-NI, VAES+AVX2, ARM) detected at runtime.

Key management

The KMS is your choice

Backend Best for How it works
HashiCorp Vault / OpenBao An existing centralized KMS/secrets infrastructure Vault's Transit engine over HTTPS; Token, AppRole, and Kubernetes JWT authentication
Local wallet Standalone deployments with no external KMS infrastructure Passphrase-protected PKCS#12 file, outside the data directory; strong derivation (PBKDF2-SHA256, 600,000 iterations, NIST SP 800-132)
PKCS#11 / HSM Regulated environments with hardware key custody The HSM's Cryptoki interface; non-extractable master key on the device. Validated with Thales, Utimaco, YubiHSM, AWS CloudHSM
KMIP roadmap v1.9 Interoperability with enterprise KMS infrastructures Not yet available — roadmap item
Security model

What it protects, and what it doesn't

Being clear about the boundary is a strength, not a weakness: TDE protects data at rest, not during processing or transit.

What it protects

A stolen or improperly disposed-of disk or storage volume.
A logical backup or snapshot that's unencrypted or sent to the wrong place.
Direct filesystem access without SQL credentials.
Tampering with stored data (detected, not accepted).

What's out of scope (by design)

Data in memory while queries are running.
Network transport: use TLS alongside TDE.
In-database authorization: a user with SELECT sees the data in cleartext. TDE doesn't replace RLS, privileges, and RBAC.
A few documented edge cases (e.g. temporary files from WITH HOLD cursors).
Regulatory alignment

In support of compliance

pg_vault_tde doesn't make an environment "compliant" on its own: compliance is a property of the whole environment. What can accurately be stated:

PCI-DSS Req. 10

Always-on audit logging maps directly onto specific 10.2.1.x sub-clauses: authentication, key lifecycle, denied access.

HIPAA §164.312(b)

The same audit logging system is documented as aligned with the audit controls required by HIPAA.

Hardware custody (HSM)

The PKCS#11/HSM integration meets requirements where the master key must never exist outside a certified hardware boundary.

FIPS & GDPR

OpenSSL can use a FIPS-validated provider (the extension claims no validation of its own). Encryption at rest supports the best practices of GDPR Art. 32.

In one sentence

Encrypt the data without touching anything

Encrypt PostgreSQL data at rest — without touching the application, the DBAs' work, or the PostgreSQL source code.

Installs with shared_preload_libraries and CREATE EXTENSION, with no recompilation. Released by Miriade under the PostgreSQL License (BSD 2-Clause): no lock-in, no GPL/AGPL code.

Related to

Support and context

Product · Annual managed support

MirCrypt

Miriade's annual support for pg_vault_tde: installation, key management, rotation, and long-term maintenance.

 Service · Control

Data Governance & Quality

Data Catalog, Lineage, and Masking: knowing which data is critical before encrypting it.

 Product · Managed service

Database Managed Service (MirDB)

Ongoing managed support for PostgreSQL databases and beyond.
FAQ

Frequently asked questions

Does it require patching the PostgreSQL core?

No. It installs as an extension (shared_preload_libraries + CREATE EXTENSION) using PostgreSQL's public APIs, without recompiling or modifying the binaries.

Do I have to change the application or the queries?

No. Encryption is SQL-transparent: tables are created with USING encrypted_heap and the queries stay unchanged.

Which PostgreSQL versions does it support?

PostgreSQL 17 and 18; PostgreSQL 19 support is on the roadmap.

Who holds the master key?

Your KMS: HashiCorp Vault/OpenBao, a local wallet, or an HSM. The master key never resides in the data directory and never travels with the backups.

Does it make me PCI-DSS or HIPAA compliant?

No: no product does that on its own. pg_vault_tde provides controls (audit, encryption, key custody) that support specific requirements such as PCI-DSS Req. 10 and HIPAA §164.312(b).

What's the performance impact?

The engine automatically uses the CPU's cryptographic acceleration (AES-NI, VAES+AVX2, ARM Crypto) detected at runtime, with no configuration.

Want to evaluate pg_vault_tde on your PostgreSQL?

Tell us about your environment (versions, KMS, security requirements): we'll help you evaluate the extension and, with MirCrypt, take it to production with ongoing support.

Request information or purchase

Write to us to evaluate pg_vault_tde

Tell us about your PostgreSQL environment and your compliance goals. By filling out the form, you can set up a technical discussion with our team to assess integrating pg_vault_tde into your architecture. Together we can:

Analyze your ecosystem: the PostgreSQL versions in use and the KMS to integrate (HashiCorp Vault, HSM, or local).
Explore the use cases: performance, infrastructure impact, and key rotation procedures with no downtime.
Assess the move to production: discovering the benefits of the ongoing, commercial support offered by MirCrypt.

Privacy and security note. Do not enter credentials, passwords, or sensitive data in the form. Any documents, data, or access needed for the assessment will be handled later through agreed secure channels.