TDE as an Extension: A Different Path for PostgreSQL Encryption
summary
An extension-first implementation builds several prototypes: an initial access-method prototype that encrypts tuples per-connection works for simple queries but causes corruption and memory spikes; switching to storage manager + WAL hooks requires a few hundred lines of core patches, adds event-trigger mapping from tables to files, and forces WAL tooling changes (pg_waldump → pgtd_waldump). Performance starts poor, improves threefold but still runs at about 60% of non‑encrypted throughput for heavy sequential workloads; a forked Percona build is currently required for production.
AI-written summary · about
chapters (21)
- 0:00Introduction and speaker welcome
- 1:09What is transparent data encryption
- 6:08PostgreSQL community efforts on TDE
- 8:37Why build an extension instead of a fork
- 10:01Access methods as encryption hook
- 12:28First prototype and its limitations
- 16:46Memory management challenges
- 17:29Performance testing and results
- 19:15Index encryption concerns
- 21:21Storage manager as new approach
- 23:10Extension points in storage manager
- 25:16Handling database object abstraction
- 27:01Edge cases like VACUUM FULL
- 28:48Partitioning and inheritance issues
- 30:32Write-Ahead Log encryption
- 32:19WAL encryption key management
- 34:05Tool compatibility with encrypted WAL
- 35:29Current limitations and open questions
- 37:56Lessons learned from development
- 39:47Q&A session part one
- 41:57Q&A session part two
related talks
43mThe Elephant Has No Clothes
34mSave the Elephants - Secure Your PostgreSQL Databases with TDE
29mA comparison of PostgreSQL Encryption Options
48mColumn encryption solutions and ideas
50mSolving PostgreSQL Wicked Problems
52mThe trouble with extensions
48mGetting To Know SQL Server Encryption Capabilities
44mOn the Road to TDE