The Dynamic Duo? | Scaling Postgres 419
PostgreSQL's lack of built-in transparent data encryption (TDE) isn't due to technical inability but a long-standing community disagreement over scope and requirements—leaving users to rely on workarounds like disk encryption, cloud provider tools, or application-level encryption. This episode dives deep into practical, real-world strategies for managing data security and performance in complex Postgres environments. From using foreign tables and materialized views together to optimize analytics across heterogeneous data sources, to avoiding the catastrophic cascade caused by long-running transactions in job queues, the host highlights critical anti-patterns and solutions. The discussion also covers emerging challenges like running AI workloads directly in the database, the risks of parallel HNSW index builds in PG Vector, and the hidden dangers of locking behaviors—especially invisible deadlocks from foreign key constraints and vacuum lock conflicts. These insights reveal that Postgres’s power lies not in its defaults, but in how carefully engineers manage its trade-offs.
Combine foreign tables with materialized views to turn slow, remote datasets into locally indexed, high-performance analytical structures.
Long-running transactions in job queues can block vacuum and cause CPU saturation—use lock timeouts during migrations to prevent cascading failures.
PostgreSQL lacks native TDE, but encryption at rest can be achieved via file system encryption (ZFS, Ceph), cloud provider tools (AWS EBS), or application-level encryption.
Running LLM calls within database transactions creates 30-second bottlenecks—move AI work to the application layer to avoid transaction timeouts.
Use jittered retries and avoid synchronous AI calls in transactions to prevent retry storms and performance degradation.
…and 3 more takeaways available in PodZeus
The Dynamic Duo: Foreign Tables + Materialized Views
“Now we've turned a slow remote dataset into a locally optimized analytical structure.”
The Cascade of Long Transactions
“The database had a snapshot as it was doing this copy, so the auto vacuum could not remove dead rows because of that current copy snapshot.”
Why PostgreSQL Lacks Transparent Data Encryption
“It is possible to have encryption at rest today without adopting a proprietary fork.”
AI in the Database: Performance Pitfalls
Running LLM calls inside Postgres transactions creates 30-second external dependencies that block entire transactions—better to handle AI work in the app layer.
PG Vector 0.8.2 and the HNSW CVE
A critical CVE in PG Vector 0.8.2 affects parallel HNSW index builds—users must upgrade immediately to avoid security risks.
“So as a quote here, now we've turned a slow remote dataset into a locally optimized analytical structure.”
“Because the database had a snapshot as it was doing this copy, so the auto vacuum could not remove dead rows because of that current copy snapshot.”
“And he says it is possible to have encryption at rest today without adopting a proprietary fork.”
Host
PostgreSQL
other
PG Vector
other
refent
other
Apache Age
other
Toast
other
ZFS
other
Ceph
other
Snowflake
organization
PGEdge
organization
PGConDev2026
other
1275: Eric Eden, Restaurateur and Co-Owner of Garden Hospitality
2h 7m • 6/1/2026
Creating checkpoints by gaslighting a Postgres database
35m • 6/9/2026
1277: Mike Cordero, chef/owner of Cordero Hospitality Group
1h 59m • 6/14/2026
Start discovering podcast insights today
Start with a 7-day trial and explore a growing catalog of popular podcasts. No credit card required.
No credit card required • 7-day trial • Cancel anytime