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 Joshua "JD" Drake 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.