Advertise on podcast: More than a refresh: Conversations with the most interesting people you've never met

EXPLAIN shows the query plan, but understanding why PostgreSQL chose it can take more digging. Testing how a database will behave under a real workload brings its own challenges, especially when a benchmark doesn’t reflect the application you support. In this Postgres Wishlist episode, Hunter O’Brien, Junior Systems Administrator and Junior DBA at Command Prompt, joins JD to talk through the tools he wishes were easier to use. His experience adapting pgbench tests leads to a conversation about reproducing application workloads and the complications of using production data in a test environment. On query plans, he wants clearer EXPLAIN documentation and more insight into the planner’s decisions. Hunter also wants a quick way to generate an entity relationship diagram (ERD) when working with unfamiliar schemas, particularly when the best documentation is a busy senior developer. Some of these needs have existing tools or workarounds; the challenge is making them practical for everyday database work.

In Part 2 of "When Postgres Is Enough", Michael Cooper and JD examine what it took for AgLedger to trust PostgreSQL with work previously split between PostgreSQL and Valkey. Supporting two databases meant maintaining separate schemas, backups, restores, and state that had to stay coordinated. PostgreSQL did not need to outperform Valkey at every task. It only needed to handle AgLedger’s workload well enough to make the second system unnecessary. Michael explains how pg-boss allowed him to move queue and rate-limiting work into PostgreSQL, and why managing connections became a more important constraint than memory. He also describes a three-hour test that subjected the system to multiple AI agents, interruptions, mutations, and adversarial attacks. PostgreSQL continued handling the workload without issue. The conversation also covers RDS IOPS, long-running snapshots, database bloat, and vacuum behavior. Once Michael trusted PostgreSQL as more than a place to store data, he began moving more schema and record structure out of application code and into the database, reducing recompilation work and making customer deployments more flexible. This episode explores the point where PostgreSQL stops being only the database and becomes the system coordinating the application around it.

James Nelson’s Postgres Love Letter comes down to reliability: being able to depend on the database as the software around it changes. In this T3D Session, James, Founder and CTO of PgCache, joins JD to explore the benefits and frustrations of PostgreSQL’s conservative approach to development. Protecting existing behavior matters to the people running applications, but so does fixing limitations they encounter in production. JD recalls earlier struggles over timestamp behavior, while James considers how forks give developers room to experiment with changes that could eventually inform core PostgreSQL. The conversation also looks at pluggable storage and the practical needs behind new extensions. James closes with the problem that led him to build PgCache: serving files at the edge while authorization requests still had to travel back to a central database.

If AI makes software easier to build, what makes it worth paying for? Lev Kokotov, creator of PgDog, joins JD for a conversation about building an open source business when writing code is becoming easier to automate. Lev uses AI daily, but sees the value of his work in the experience needed to operate software that customers depend on. That raises a practical question: when does building something yourself make sense, and when is a supported product worth the money? PgDog brings that question into focus. Drawing on his experience at Instacart, Lev explains his approach to scaling PostgreSQL through load balancing and sharding, including the operational challenges that remain once the code is written. He and JD examine what customers get from paid support and how to build a business around software people can use for free. The conversation also reaches beyond software. JD and Lev share examples of AI making their own work easier, but differ on how society will adapt as more tasks become automated. Their exchange explores what those changes could mean for people whose livelihoods depend on the work AI can now help perform.

What would it take for PostgreSQL materialized views to stay current as the underlying data changes? In this Postgres Wishlist episode, Brian joins JD to explore his request for real-time materialized views. Brian has built trigger-based solutions for simpler cases, but keeping aggregate results up to date becomes more involved as queries grow complex. For applications such as a live scoring site, waiting for the next refresh means showing results that no longer reflect the latest activity. The conversation explores possible approaches and their trade-offs, then turns to a more targeted request: refreshing only the relevant portion of a materialized view. If only some customers have new activity, why recalculate results for everyone? Brian and JD consider what more flexible refresh behavior could offer and the implementation questions that remain open.

Can an AI service work with your data without seeing it? In part two of Better AI, our six-part series from More Than a Refresh Presents: T3D Sessions, Reza Rassool of Kwaai and JD explore how homomorphic encryption could protect the information people share with AI systems. Reza explains how computations can run on encrypted data, with encrypted results returned to the user for decryption. He describes the performance challenges of fully homomorphic encryption and Kwaai’s research into partially homomorphic approaches intended to run on consumer laptops. The conversation also introduces Virtual Private Knowledge (VPK), a protocol Kwaai is developing to let users access AI compute while keeping their data private from the service provider. Reza outlines plans for a Linux Foundation working group focused on homomorphic encryption, while JD asks what would lead major AI providers to adopt this approach. Learn more about Kwaai and its work at https://kwaai.ai.

PostgreSQL logical replication can provide a selective stream of data changes, but what happens when the schema itself changes? James Nelson, Founder and CTO of PgCache, shares his Postgres wishlist: more information about DDL and schema changes in the logical replication stream. For systems that use replication events to keep a cache current, a dropped table can create a serious blind spot when there is no corresponding event to invalidate its cached data. James and JD explore why consuming the binary replication stream is not always a practical alternative, including the volume of cluster-wide data and potential security concerns. They also consider possible workarounds using custom messages and triggers, and what a lightweight, opt-in approach could make possible for PostgreSQL extensions.

We're kicking off When Postgres Is Enough, a new three-part T3D series with Michael Cooper, founder of AGLedger. Michael and JD follow how a data-sovereignty requirement put an entire application stack on trial, and why PostgreSQL kept winning. In Part 1, Michael explains how AGLedger started with a conventional AWS-based SaaS architecture. The product records AI agents' intentions and reported actions, preserving context so work can resume later. Keeping that information inside the customer's environment meant rethinking the product as a self-contained service that could operate without phoning home. PostgreSQL was already part of the stack through RDS, but every additional dependency raised questions about what Michael would need to deploy and support. Drizzle was the first component he removed, after repeatedly having to work out whether database problems came from ORM configuration or SQL. This opening episode traces the decisions behind that shift toward self-hosting and a simpler stack. It sets up the central question of the series: how much of what you're building actually needs something beyond PostgreSQL?

This episode launches Better AI, a new six-part series from More Than a Refresh Presents: T3D Sessions, with Reza Rassool of Kwaai and JD. The series opens with a question about AI safety: who controls the data you share with AI tools? The conversation raises a practical question about how much control they retain when they depend on someone else’s platform. Reza Rassool: https://www.linkedin.com/in/rezarassool/ Kwaai: https://www.linkedin.com/company/kwaailab/

What should PostgreSQL do when a query plan expects 10 rows and gets 10,000? In this Postgres Wishlist episode, Greg Dostatni and JD explore how better feedback from query execution could help DBAs understand where estimates go wrong. Greg’s wishlist starts with a plan explorer that would reveal the alternatives PostgreSQL considered but didn’t choose, along with their estimated costs. He also makes the case for adaptive query plans that could reconsider unfinished work when actual row counts differ significantly from estimates. JD questions how much should happen automatically in production and suggests keeping that experimentation within EXPLAIN ANALYZE. That raises another possibility: tracking estimation errors over time so DBAs can see where the statistics model repeatedly misses the mark. Instead of investigating each mismatch in isolation, could PostgreSQL retain enough history to help identify where statistics need attention? The conversation then turns to PostgreSQL upgrade testing. Greg wants to replay production workloads in a test environment and compare performance before committing to a change, while JD imagines what an integrated workload replay system could look like. Greg also questions whether upgrade cutovers could become gradual, with traffic moving between versions as confidence grows. What would you add to the PostgreSQL wishlist?

What happens when an open source project receives more AI-generated submissions than its maintainers can reasonably review? At Turso, it meant shutting down a bug bounty program that had uncovered real bugs and led to two hires. Glauber Costa, CEO of Turso, explains how the program became overwhelmed while his team was building a new implementation of SQLite in Rust. Plausible but invalid bug reports took time to investigate, and automated appeals kept arriving after submissions were rejected. Attempts to filter them through a reputation system weren't enough to keep the program running. Glauber and JD explore how open source projects can hold contributors accountable for AI-generated code while remaining open to new people. Drawing on his experience in the Linux kernel community, Glauber makes the case for a reputation system that lets contributors improve. He also describes how AI helped him return to hands-on development after years focused on running a company, and why he remains committed to open contribution. How is your team handling AI-assisted contributions? Share your approach in the comments.

PostgreSQL may be close to perfect, but a few edge cases still leave room for improvement. In this Postgres Wishlist session, Ildefonso Camargo looks at some of the friction around LDAP authentication, including the need to store bind credentials in pg_hba.conf and the risk of those credentials appearing in connection logs. He and JD explore alternatives such as PAM and Kerberos, along with the added complexity those solutions can introduce. The conversation also turns to large objects and a long-standing limitation in PostgreSQL logical replication: large objects are not replicated. JD explains why large objects still have useful characteristics, particularly their ability to stream large files without loading the entire object into memory, and why their legacy status has limited further development. Ildefonso closes his wishlist with another authentication challenge: even when PostgreSQL relies on an external authentication system, users still need to be created inside the database. It’s a technical look at a handful of PostgreSQL edge cases where existing workarounds solve part of the problem, but not always without tradeoffs.

AI is changing more than how work gets done. It is changing what becomes possible for the people doing it. In this episode of More Than a Refresh, Nikki Barua joins JD for a conversation about what happens when experience, judgment, and curiosity meet tools that can dramatically shorten the distance between an idea and its execution. They explore why access to AI is not enough, why leaders need to work with the technology firsthand, and why the people who benefit most may be those willing to question old roles, rethink how they create value, and become builders again. The conversation also turns to identity, accountability, and the qualities that become more valuable as average work gets easier to automate. Nikki shares how professionals can move beyond titles and job descriptions to identify the gift they uniquely bring, then use AI to expand what they are capable of building. At its core, this is a conversation about reinvention. Not replacing human value, but learning how to recognize it, develop it, and put it to work in a new era. 🔗 Nikki Barua: https://www.linkedin.com/in/nikkibarua/🔗 FlipWork: https://www.linkedin.com/company/flipworkai/

PostgreSQL major version upgrades still require more moving parts than many database teams would expect. In this Postgres Wishlist episode, James and JD examine why upgrading in place remains difficult, how pg_upgrade depends on binaries from the previous version, and why the process becomes increasingly awkward across modern deployment environments. Could PostgreSQL eventually support a major version upgrade with little more than a restart? James considers cross-version streaming replication as another possible path, while JD explores a hybrid approach that would replicate system objects logically and user data in binary form. From pg_upgrade and logical replication to RDS, disk formats, rollback, and operational downtime, the conversation examines what prevents PostgreSQL from offering a simpler upgrade path and what a more practical architecture could look like.

The PostgreSQL planner doesn't make random decisions. Every execution plan is shaped by statistics, cost estimates, and the information available at the time. Understanding those decisions can completely change the way you approach database performance. In this Postgres Love Letters episode, JD and Hunter O'Brien explore how learning to read query plans transformed the way Hunter works with PostgreSQL. What once seemed like a black box became a system with clear reasoning, making it easier to diagnose slow queries, understand performance bottlenecks, and make informed tuning decisions. The conversation also explores the value of PostgreSQL's transparency. From real-world examples of dramatically improving query performance to the flexibility of influencing planner behavior when needed, they discuss why understanding what's happening under the hood remains one of PostgreSQL's greatest advantages over more opaque managed database platforms. Whether you're troubleshooting slow queries or simply want to better understand how PostgreSQL thinks, this episode offers practical insight into one of the database's most important components.