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 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.