Postgres and Open Source Experts

Why does current AI need so much compute to produce an answer?

In episode three of “Better AI,” our six-part series from More Than a Refresh Presents: T3D Sessions, Reza Rassool of Kwaai and JD Drake begin a two-part look at faster AI. They compare current neural networks with biological intelligence, which can learn while thinking and make a fast initial decision without processing every detail first.

Reza explains that current AI separates training from inference and passes input through multiple layers before producing a result. The connections between those layers can cause computation to grow quadratically as inputs expand, while larger context windows add further load.

He also contrasts human memory with LLM weights, where a specific fact cannot be located and edited directly. The episode closes with Kwaai’s research into the “blink transform,” an approach intended to change the relationships within a neural network so computation grows linearly rather than quadratically as the network increases in size.

Learn more about Kwaai and its work at https://kwaai.ai.

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.

For decades, enterprise software has carried an assumption: if it costs more, it must be better. PostgreSQL challenges that idea.

In this Postgres Love Letter episode, Brian and JD reflect on what first drew them to PostgreSQL and why their appreciation for it has only grown over the years. What begins as a conversation about open source quickly becomes a broader look at performance, reliability, long-term cost, and the misconceptions that still surround enterprise databases.

From organizations saving millions by moving away from proprietary databases to cloud providers building services on PostgreSQL, this conversation explores why more businesses are rethinking what they actually need from a database. Choosing PostgreSQL isn't just about spending less. It's about questioning the assumption that enterprise software has to be expensive to be reliable, capable, or ready for production.

Whether you're evaluating a new application, planning a migration, or simply challenging long-held assumptions about enterprise databases, this episode offers a practical perspective on why PostgreSQL continues to earn the trust of organizations of every size.

Does AI really need another massive data center? Or have we overlooked the computing power that's already sitting idle on millions of devices?

In this episode, JD is joined by Reza Rassool, Chair and CEO of Kwaai, a nonprofit AI lab building open source AI infrastructure around a different idea: instead of concentrating AI in a handful of massive facilities, why not build a distributed network that makes use of the hardware people already own?

That question leads into a broader conversation about sustainability, privacy, distributed computing, and the future of AI infrastructure. Reza explains how technologies like homomorphic encryption could make distributed AI practical without sacrificing privacy, while JD brings an engineering perspective on data centers, energy use, and what it would actually take to make this model work at scale.

Whether or not this becomes the future of AI, it's a conversation that challenges one of the industry's biggest assumptions.

Faster schema changes sound like an obvious improvement. But as this conversation shows, making one database operation faster can introduce performance problems that are much harder to spot.

In this Postgres Pet Peeves episode, Brian shares a real production case where adding a column with a default value led to unexpectedly slow queries. JD and Brian explore why PostgreSQL behaves this way, how the optimization introduced in PostgreSQL 11 changes what is actually written to disk, and why that can leave the query planner working with incomplete information until the table is eventually rewritten.

The conversation goes beyond a single edge case. It highlights an engineering reality that applies well beyond PostgreSQL: every optimization has trade-offs, and understanding those trade-offs is often the difference between a smooth deployment and days spent chasing an unexpected performance issue.

Whether you manage production PostgreSQL systems, build migration workflows, or simply enjoy understanding how PostgreSQL works under the hood, this episode offers a practical look at a subtle behavior that can have a surprising impact in the real world.

What if the biggest barrier to interoperability isn't your data, but the expectation that everyone has to use the same model?

In this episode, JD is joined by Amy Rose, CTO of Overture Maps Foundation, to explore why interoperability depends less on forcing systems into a common schema and more on helping different systems communicate. Using global mapping data as an example, Amy explains why organizations should be able to preserve their own structures, formats, and ownership while still making their data easier to discover, connect, and use.

The conversation also explores the unique challenges of working with geospatial data at global scale, from geometry and file formats to persistent identifiers that allow independent datasets to work together. Along the way, it becomes a broader discussion about database design, open data, and why interoperability is ultimately a data architecture problem, not a standardization problem.

Whether you're building data platforms, designing APIs, working with PostgreSQL, or thinking about the future of distributed systems, this episode offers a practical perspective on connecting data without forcing every system to look the same.

In this episode, Command Prompt Founder JD talks with Marcel Kornacker, CTO and Co-Founder from Pixeltable, about why AI is changing what developers need from their databases. Drawing on decades of experience building large-scale data systems, Marcel explains why modern AI applications require more than traditional approaches to storing and managing data.

As AI expands beyond text into images, video, audio, and multimodal workflows, developers are spending more time moving, transforming, and orchestrating data than building the applications themselves.

Marcel explores why these challenges exist, where traditional databases fall short, and how rethinking the role of the database can simplify AI development without adding unnecessary complexity.

Whether you're building AI-powered products, designing data platforms, or exploring the future of database systems, this conversation offers a practical perspective on how AI workloads are reshaping modern application architecture.

What begins as a conversation about AI, open source, and developer ecosystems quickly grows into something much broader. Pauline and JD explore hacktivism, Anonymous, Scientology, institutional trust, healthcare, politics, and the challenges of navigating an increasingly polarized world.

Throughout the episode, Pauline brings a thoughtful perspective to complex topics, arguing that many of today's biggest debates resist simple answers. Rather than reducing technology, institutions, or public policy to absolutes, she explores the tradeoffs, incentives, and human factors that shape how these systems evolve and why understanding nuance matters more than ever.

Whether the conversation is about open source software, digital activism, religion, healthcare, or geopolitics, this episode is a reminder that the most interesting discussions often begin where certainty ends.

In this Postgres Love Letters episode, JD is joined by Greg Dostatni, Engineer at Command Prompt, to explore one of PostgreSQL's greatest strengths: the freedom that comes from being open source. What begins as a conversation about licensing quickly expands into portability, transparency, community innovation, and why PostgreSQL continues to give organizations choices that many proprietary databases cannot.

Greg explains why having access to the source code matters, how PostgreSQL's ecosystem of extensions keeps the platform evolving, and why businesses using managed database services still benefit from PostgreSQL's open foundation. Together, they discuss vendor lock-in, portability across platforms, and why protecting your data also means protecting your ability to move it.

Whether you're running PostgreSQL on-premises or in the cloud, this conversation offers a practical perspective on why openness remains one of PostgreSQL's greatest long-term advantages.

In this episode, JD talks with Sugu Sougoumarane, Head of Multigres at Supabase and co-creator of Vitess, about one of the biggest engineering challenges facing large PostgreSQL deployments: how do you scale beyond a single database without replacing PostgreSQL?

Drawing on his experience building Vitess and now leading Multigres, Sugu explains why PostgreSQL is reaching a new stage of growth and why scaling it requires much more than simply sharding data. Together, he and JD explore the architectural decisions behind distributed transactions, resharding, consistency, and the infrastructure needed to help PostgreSQL scale while preserving what already makes it successful.

Whether you're building high-growth applications, planning for larger PostgreSQL deployments, or interested in distributed database architecture, this conversation offers a practical look at the challenges and tradeoffs behind scaling PostgreSQL without replacing it.

PostgreSQL is one of the most trusted databases in the world. So why do backups, recovery, and day-to-day operations still feel harder than they should?

In this Postgres Pet Peeves episode, Command Prompt Founder JD and Command Prompt CIO Ildefonso Camargo explore the gap between PostgreSQL's maturity as a database engine and the operational experience surrounding it. From the renaming of pg_xlog to pg_wal, to backup tooling, recovery workflows, and administrative complexity, they discuss why some of PostgreSQL's most persistent frustrations exist outside the database itself.

The conversation looks at how small usability decisions can lead to costly mistakes, why operational tooling matters just as much as database features, and what PostgreSQL still needs to become easier to manage in production environments.

In this episode, JD talks with Phenom strategist Cliff Jurkiewicz about hiring, artificial intelligence, and why most conversations around AI miss the practical reality of how people actually work.

Cliff argues that AI should be used to reduce repetitive tasks and speed up execution, not replace human judgment, creativity, or communication. The conversation explores hiring trends, layoffs, AI-assisted resumes, and why companies still need people who can think critically, tell stories, build trust, and drive outcomes.

JD and Cliff also get into the difference between using AI as a shortcut versus using it as an accelerator. From proposal writing to research and ideation, the discussion stays focused on practical usage instead of hype.

This episode is a grounded conversation about where AI genuinely helps, where human value still matters most, and why faster output is not the same thing as meaningful work.

In this episode, JD talks with Andrew Aitken, Founder of the Center for Rural AI, about what AI adoption looks like outside major cities and tech hubs.

Andrew shares how the organization is working with rural communities, higher education, municipalities, and small businesses to help people better understand and use AI tools in practical ways.

The conversation includes examples ranging from local workshops in small Colorado towns to AI-assisted tools for hospitality, tourism, and accessibility.

But the discussion quickly expands into larger questions around access and participation. JD and Andrew talk about broadband infrastructure, rural entrepreneurship, the cost of AI tools, and whether communities outside large urban centers will realistically be able to keep up with the speed of technological change.

They also explore sovereign data, Native American communities, and the challenge of ensuring that AI systems represent people and cultures accurately instead of flattening them into generic datasets.

The episode touches on ownership, equity, economic opportunity, and the growing tension between rapid AI development and the communities trying to adapt to it.

This is a conversation about AI, but it’s really a conversation about access, identity, and whether the next wave of technology will widen existing gaps or help close them.

In this Postgres Pet Peeves episode, JD talks with Jonah Harris about one of PostgreSQL’s oldest and most debated architectural choices: MVCC and the storage behavior that still shapes how PostgreSQL handles updates, concurrency, and vacuum today.

Jonah explains how PostgreSQL originally supported time-travel queries, allowing users to inspect historical versions of data directly, and why PostgreSQL still stores and manages data the way it does even after those original features disappeared decades ago.

From there, the conversation digs into the real consequences of PostgreSQL’s MVCC model. Instead of updating rows in place, PostgreSQL continuously creates new row versions, leading to vacuum overhead, index churn, table bloat, and storage inefficiencies that engineers still fight with today.

This episode goes deep into PostgreSQL internals, but at its core it’s a conversation about how long architectural decisions can shape the future of a database system long after the original reasons for them disappear.

In this episode, JD talks with MotherDuck Co-Founder and CEO Jordan Tigani about how AI agents are starting to change the way teams explore and interact with data.

The conversation begins with a practical question: can AI actually help business users work directly with analytics without needing to know SQL? Jordan explains why newer agent-based systems behave differently from earlier natural language query tools. Instead of generating a single query and hoping for the best, these systems can iteratively inspect tables, test joins, explore schemas, and refine answers in ways that look much closer to how a human analyst works through a problem.

This episode is less about AI hype and more about the practical tension between automation, context, and how people actually use data inside real businesses.

In this Postgres Pet Peeves episode, JD talks with Ryan Booz from PG Analyze about a problem many PostgreSQL teams run into far too late: the visibility you need often is not enabled when things start going wrong.

The conversation starts with logging and query optimization, but quickly expands into a bigger discussion around PostgreSQL’s configurability and why so many critical settings still feel hidden to everyday users.

Ryan explains why teams regularly discover tools like pg_stat_statements only after performance issues appear, and why troubleshooting production systems often starts with realizing the data was never being collected in the first place.

JD and Ryan also discuss conservative defaults, auto-tuning, and the tension between building PostgreSQL as a general-purpose product versus running PostgreSQL in real production environments.

It becomes a broader conversation about observability, operational reality, and the growing number of companies building solutions around gaps the community still debates.

In this episode, Bradon Rogers, Chief Customer Officer at Island, joins JD to break down how enterprise environments became so complex. Over the years, organizations have taken a consumer web browser and layered on proxies, VPNs, data loss prevention tools, and other controls to manage access and security.

The result is a fragmented stack that works for the organization, but often creates a poor experience for the end user.

Bradon explains why this approach persists and what happens when you shift the model. Instead of wrapping the browser with layers of infrastructure, the conversation explores what it looks like to move identity, context, and control directly into the browser itself, turning it into the point where application access is governed.

They also touch on practical implications, like separating personal and corporate activity and simplifying how users interact with both internal and external applications.

In this Postgres Pet Peeves episode, Justin Graf and JD take on a long-standing issue in PostgreSQL: transaction IDs (XIDs) and what happens when they wrap around. Despite years of improvements, the system still relies on a 32-bit design that forces ongoing maintenance in high-volume databases.

This short session offers a practical look at why XIDs still matter and how they continue to shape performance and operations in modern Postgres environments.

In this episode, Joris Kuipers, CTO and hands-on architect, joins JD to talk about what it really means to grow as an engineer. As AI begins to take on more of the straightforward coding work, the conversation shifts to the skills that actually define long-term value.

Joris explains why writing code is only one part of the job. Understanding customer problems, communicating effectively, and taking ownership of outcomes are what move engineers forward.

The discussion also explores how to grow into leadership without losing touch with the technical side, and why that balance matters.

JD and Thomas Carnevale, Founder of Umbrella Security, get into how modern security infrastructure connects to questions around control, authority, and ownership.

What begins with cameras, access control, and surveillance quickly turns into a discussion about who actually decides what we can access, what gets stored, and how those systems evolve over time.

They also get into the tension between protection and control. Identity verification, monitoring, and centralized systems are often framed as necessary safeguards, but they also introduce new layers of dependency and influence.

It is a conversation about security, but also about control, trust, and what it means to actually own the systems you rely on.

In this Postgres Pet Peeves episode, Greg Dostatni and JD take on a problem most teams run into early but rarely question: default configuration. PostgreSQL ships with hundreds of parameters, many of which are still based on assumptions from decades-old hardware. For new users, that doesn’t feel like flexibility, it feels like noise.

Greg breaks down why this creates unnecessary complexity and why, in practice, most teams don’t need to understand all 400 settings. They need to understand the right ones.

The conversation also touches on how this has become less of a technical limitation and more of a usability and community challenge over time.

Adding a column with a default value feels like a safe change. It is fast, avoids locking, and keeps things moving. But in Postgres, that speed comes from a tradeoff that can quietly affect performance later.

Brian Fehrle, Database Administrator at Command Prompt, explains how Postgres handles these defaults without writing them to disk, and why that can leave the query planner working with incomplete information.

In this episode, a real production case shows how queries that were once fast suddenly slowed down after a schema change, and how fixing it required more work than expected. It is a small decision with consequences that only show up when the system is under pressure.

In this episode, Denis Magda, author of Just Use Postgres, joins JD to talk about how PostgreSQL is often misunderstood. Many developers still approach Postgres as a traditional relational database, even though it has evolved far beyond that.

Denis shares how he personally rediscovered Postgres while exploring its modern capabilities, from native JSON support and full-text search to extensions for time-series and vector workloads. For many teams, these features are already available, but rarely used.

The idea behind “Just Use Postgres” is not about forcing a single solution. It’s a practical reminder: before introducing another database into your architecture, take a closer look at what Postgres can already handle.

Just Use Postgres!: https://www.manning.com/books/just-use-postgres

In this episode, Pauline Vos, software engineer and open source maintainer for MongoDB’s PHP ecosystem, breaks down a reality most teams overlook: the open source libraries your product depends on may be maintained by a single person with no long-term guarantees.

What happens when that person steps away? Pauline explains why companies need to actively invest engineering resources into maintaining their surrounding open source ecosystem; not just for stability, but to reduce risk, improve developer experience, and build strategic relationships within key frameworks.

From client libraries to community goodwill, this conversation reframes open source not as a dependency, but as part of the product itself.

Whether you’re leading engineering, managing infrastructure, or building developer-facing tools, this episode highlights a critical shift: relying on open source isn’t enough, you have to support it.

Welcome to Episode 55 of More Than a Refresh, where JD sits down with Kellyn Pot’Vin-Gorman, Developer Advocate at Redgate, for a candid conversation about AI, governance, and the economics shaping today’s technology landscape.

From database culture and open source philosophy to AI monetization models and corporate risk, this episode explores a central tension: if data is the product, who actually benefits?

Kellyn shares why governance must come before adoption, why many organizations implement AI without defining the problem they’re solving, and why internal behavior—not external attackers—often creates the biggest security risk.

This is a grounded, unfiltered look at the intersection of technology, responsibility, and profit—and what it means for the people building and using these systems.

In this episode of More Than a Refresh: T3D Sessions, Marijn Markus, AI Lead and Managing Data Scientist at Capgemini, breaks down a question most teams aren’t asking clearly enough: What happens when the majority of what we see online isn’t coming from real people?

The conversation moves beyond AI hype into something more immediate.

Marijn explains the difference between misinformation and disinformation, how bot-driven narratives scale faster than truth, and why outrage has become a business model. From fake personas to coordinated information campaigns, this is a grounded look at how digital systems shape perception, trust, and decision-making.

Whether you’re leading a team, building products, or making strategic calls based on online signals, this episode offers a sharper lens on what you’re actually seeing and what you might be missing.

In this episode, JD talks with Thomas Carnevale, founder of Umbrella Security, about a gap most people don’t realize exists until it’s too late: the difference between systems that look secure and systems that actually deter. Cameras are everywhere, and that’s exactly the problem.

As Thomas explains, visibility alone doesn’t stop anything anymore. Real security requires response, timing, and systems designed to interrupt behavior, not just record it.

Drawing from decades of experience designing enterprise and government security infrastructure, Thomas walks through what effective protection actually looks like today, where “AI” fits into the picture, and why human judgment still needs to stay in the loop.

Learn more about Umbrella Security Systems: https://umbrellasecurity.com/

In this episode, JD sits down with Andrew Bolton, Co-Founder and CEO of Tech Rescue, to explore what happens when a hyper-connected world leaves millions behind. What starts as a conversation about 24-hour technical support quickly expands into something bigger: access to healthcare, logistics, and the growing gap between technology’s capabilities and real human support.

Andrew explains how 80 million Americans have been left behind by rapid technological change, including 16 million without reliable access to essential healthcare services .

Tech Rescue positions itself as more than IT support. It operates as a 24/7 life concierge, coordinating everything from doctor appointments and transportation to navigating smart home devices and connected systems. From punch cards to smartphones more powerful than moon-landing computers, this conversation examines the paradox of modern infrastructure: we are more connected than ever, yet many people still struggle to access basic services.

In this episode, JD sits down with Hunter O’Brien to break down one of the most misunderstood areas of AWS: Identity and Access Management (IAM). Designing policies sounds straightforward, until wildcards, over-permissioned roles, and unclear resource access create real risk in production.

Hunter explains how the AWS IAM Policy Simulator allows teams to safely test roles before they reach production. By simulating API calls without affecting live systems or billing, organizations can design least-privilege policies, validate MFA enforcement, and avoid accidental overexposure.

Welcome to episode 55 of More Than a Refresh. In this episode, JD talks with Samantha Baldwin, Policy & Research Staff Technologist at the Electronic Frontier Foundation (EFF), about the growing push for age verification laws in the United States. These proposals are often framed as protecting children online. But what do they actually require from operating systems, platforms, and users?

They discuss how these laws work, why many may be technically ineffective, and what the long term implications could be for digital rights, anonymity, and online speech.

Samantha is a Policy & Research Staff Technologist on EFF's Public Interest Technology team.

In this Postgres Pet Peeves episode, JD sits down with Yurii Rashkovskii to unpack a frustration many experienced engineers quietly share: why is Postgres so difficult to evolve?

The conversation centers on architecture. From tightly coupled storage and transaction layers to row-oriented execution models, Yurii explains why experimenting with new storage engines or fundamentally different designs inside Postgres is far from simple. What looks modular on the surface often reveals deep interdependencies underneath.If you’ve ever pushed Postgres beyond the “average install” and hit architectural ceilings, this episode will resonate.

In this episode, JD sits down with Command Prompt CIO Ildefonso Camargo to challenge a common assumption in modern infrastructure: If you can afford the cloud, why wouldn’t you use it? What starts as a simple cost comparison turns into a deeper discussion about accounting realities, hardware depreciation, staffing requirements, compliance, and operational risk. Ildefonso shares what sparked the conversation—seeing a large enterprise sign a long-term cloud contract with a massive monthly bill—and questioning whether owning infrastructure might actually make more financial sense.

In this episode, JD sits down with Amanda Nystrom, CEO of Command Prompt and National Board Certified Health & Wellbeing Coach, to talk about wellness for people in tech and why most advice misses the point.

Rather than focusing on quick fixes, discipline, or one-size-fits-all tools, Amanda explains why awareness has to come first. They explore how environment, nervous system load, work culture, and internal narratives all shape health outcomes, often more than diet or exercise alone.

In this episode, Joshua “JD” Drake talks with Lev Kokotov, creator of PGDog, about one of the hardest problems in PostgreSQL: horizontal scaling in real production systems.Lev shares lessons learned from scaling Postgres at Instacart during periods of extreme growth, and why existing approaches often fail when applied to large, established applications.

They explore what happens when rewriting millions of lines of code simply isn’t an option—and why tooling needs to adapt to applications, not the other way around.

Welcome to Episode 54 of More Than a Refresh, where JD sits down with Kevin Jernigan to talk about AI hype versus reality, the real limits of scaling large language models, and why more data centers don’t necessarily mean smarter systems.

They explore the economic and technical constraints behind today’s AI boom, what current models get fundamentally wrong, and what it would take to move beyond pattern matching toward something more meaningful.

In this episode, JD sits down with Brian Fehrle to unpack a deceptively simple PostgreSQL operation that can trigger serious performance issues: adding a new column with a default value.

Brian explains how PostgreSQL’s optimization—introduced to avoid table rewrites and long locks—can leave data “virtual” rather than physically written to disk. While this makes schema changes faster, it can quietly confuse the query planner, skew statistics, and turn previously fast queries into production problems, especially when the new column is used in WHERE clauses.

This episode is a must-listen for DBAs, Postgres operators, and engineers managing large PostgreSQL workloads—especially in cloud environments—who want to avoid subtle changes that can cascade into days of degraded performance.

In this episode, JD is joined by Alan Lazaros for a conversation about systems, consistency, and the long game behind meaningful progress. While most people focus on big breakthroughs, this discussion explores how small, intentional actions—repeated daily—compound into exponential results over time. Drawing from personal experience and years of coaching, Alan reflects on health, wealth, relationships, and fulfillment as interconnected systems. Rather than chasing intensity or quick wins, the episode reframes growth as something built gradually, through steady effort and long-term thinking.

In this AWS-focused episode, Command Prompt Founder JD talks with James Campbell about one of the most common (and most expensive) sources of cloud surprises: storage choices.

James breaks down how AWS offers an overwhelming number of options across EBS, S3, and Glacier tiers, and why “flexibility” often translates into misconfiguration, avoidable spend, and hidden performance bottlenecks.They also dig into a frequent pain point: backups and snapshots.

JD and James explain what people misunderstand about AWS snapshots, why “snapshot completion time” can be deceptive, and how resilience assumptions can fall apart if you don’t plan for availability zone / region boundaries and the time it takes to copy data across them.

If your AWS bill feels unpredictable—or your retention and DR plan is more hope than strategy—this episode reframes storage as a first-class architecture decision, not an afterthought.

In this episode, Command Prompt Founder JD talks with Glauber Costa about AgentFS, a virtual file system designed to solve one of the hardest problems in modern AI infrastructure: managing state and data isolation for fast-moving, sandboxed AI agents.

Glauber explains how AgentFS treats the data layer as part of the sandbox itself, enabling agents to snapshot, move, and resume execution in milliseconds without relying on heavy infrastructure.

They explore why traditional systems become too slow and complex as agent-based workloads scale, how representing an agent’s state as a lightweight, SQLite-backed file system enables rapid mobility, and why rewriting SQLite in Rust was necessary to address concurrency and performance limitations.

The conversation offers a practical look at how AI is pushing infrastructure toward lighter, faster, and more state-aware designs.

JD welcomes back Andrew Sullivan, former Chair of the Internet Architecture Board and former President & CEO of the Internet Society.

Listen in as they continue their conversation on the “enshittification” of the internet, how consolidation and regulation are reshaping a network built on open standards, and why we may be closer than we think to losing the internet as we once knew it.

JD sits down with Amanda Nystrom to explore an often-overlooked reality in the tech industry: wellness is not a personal side concern—it’s a performance issue.

Drawing parallels between system audits, Postgres health checks, and human behavior, Amanda explains why teams can’t expect long-term reliability, scalability, or high performance if they ignore the health of the people behind the systems. Just as neglected infrastructure leads to outages and technical debt, ignored habits and burnout eventually undermine human performance.

This conversation reframes wellness in terms engineers understand: sustainability, performance, and future readiness.

If you care about building resilient systems, this episode makes the case for building resilient people, too.

In this episode, Command Prompt Founder Joshua “JD” Drake talks with Andrew Smith, Senior Developer/DBA, about a foundational concept in software engineering that quietly powers modern systems: code generation and single sources of truth.

Andrew walks through the evolution of code generation—from early macros and assembly language to modern model-driven architectures—and explains why generating code from a centralized definition is one of the most effective ways to build scalable, maintainable systems. Using practical examples from C, PostgreSQL, and modern frameworks, he breaks down how code generation reduces duplication, prevents drift, and keeps complex systems aligned over time.