Talking Postgres with Claire Giordano

How does a fix for psql tab completion turn into 25 years of contributing to Postgres? In Episode 43 of Talking Postgres, Peter Eisentraut—PostgreSQL committer, core team member, SQL standards contributor, and Chief Architect of Database Servers at EDB—joins Claire to trace that journey. We dig into how scratch-your-own-itch development drew him in, why “the things you do, people welcome them” kept him coming back, and how Postgres changed as it grew from a small database community into a massive ecosystem where, from the Postgres mailing list perspective, “most of the user base is silent.” Plus: what it feels like when code you commit goes straight to everybody who uses Postgres, and the implications of the EU Cyber Resilience Act.Previously on Talking Postgres:Talking Postgres podcast Ep24: Why mentor Postgres developers with Robert HaasTalking Postgres podcast Ep26: Open Source Leadership with Bruce MomjianTalking Postgres podcast Ep32: The Fundamental Interconnectedness of All Things with Boriss MejíasLinks mentioned in this episode:Conference: FOSDEM 2027LinkedIn: FOSDEM PGDay 2027 announcementConference: Prague PostgreSQL Developers Day (P2D2)Conference: PGDay Lowlands 2026 (the “friendliest” conference)Conference: PGConf EU 2026 in Valencia on 20-23 OctPGConfEU Conference talk: What does the EU Cyber Resilience Act mean for PostgreSQL and its communityWikipedia: EU Cyber Resilience ActPGConf.dev on LinkedIn: PGConf.dev accountPGConf.dev conference talk: Committer Review: An Exercise in Paranoia, by Robert HaasPostgreSQL.org: CommittersPostgreSQL mailing list: Postgres 19 release management teamBlog: Peter Eisentraut BlogBlog post: Where are all the PostgreSQL users, by Peter Eisentraut PGCA non-profit: PostgreSQL Community AssociationBrett Cannon at PyCon 2014: I came for the language but I stayed for the community Planet PostgreSQL: Blog aggregation feedIn this episode, we covered:00:00 Intro & music02:14 Tinkering with the Commodore 64 07:57 The itch that became psql tab completion15:43 Had to make opportunities23:05 From posting at night to posting during the day24:40 Why he stopped committing in the afternoon28:04 On the ground floor of something that grew30:34 What the Postgres core team actually does31:47 Borrowing ideas from other OSS projects36:51 Bringing Postgres into the SQL standards process38:40 Getting to hang out with database nerds42:01 Mentoring Postgres contributors50:56 Making time for Postgres conferences53:35 What the Cyber Resilience Act means for Postgres57:36 Where are all the Postgres users?1:07:00 Becoming a committer early on in Postgres1:16:22 Contributing to Postgres isn't just writing code1:19:40 Why FOSDEM is still his favorite1:22:15 Finding familiar problems in a compiler devroom1:26:14 Shout-out to the Planet Postgres feed

What’s your gold standard for deciding whether AI-written code is ready for production? In Episode 42 of Talking Postgres, Simon Willison—creator of Datasette, co-creator of Django, and prolific open-source developer—joins Claire to share how AI is changing the way he builds software today. We dig into why his test for shipping AI-generated code is “Could I explain this to somebody else?”, how engineering management skills can be surprisingly useful when managing AI agents, and how the bottleneck is no longer writing code but understanding it. Also: personal credibility, deep research, the Winchester Mystery House, slop proxies, and Simon’s observation that “Features are cheap. That doesn’t mean you should build them all.”Previously on Talking Postgres:Talking Postgres podcast Ep 30: AI for data engineers with Simon Willison Links mentioned in this episode:Blog: Simon Willison’s BlogProject page: Datasette, for finding stories in dataGitHub repo: sqlite-utilsBlog post: Release of alchemy-utils 0.1a0 (featuring Postgres & DuckDB)Blog post: There are no lossless transformations of natural-language text, by Sophie AlpertPodcast episode: The Open Weight Revolution with Simon Willison, on Oxide and FriendsPodcast episode: An AI state of the union, on Lenny’s Podcast Wikipedia: Winchester Mystery HouseIdea in Mythical Man-Month: Conceptual integrityBlog post: SQLite compressed text-history prototypes, by Simon WillisonTools: Simon’s miscellaneous tools repoIn this episode, we covered:00:00 Intro & music04:00 A week of work before breakfast09:12 Red-green TDD makes agents exercise every line14:42 A million lines mean nothing if you don’t understand it18:28 Finding low-hanging fruit among open PRs & issues22:07 Getting work done while walking the dog23:01 Gold standard: “Could I explain this to somebody else?”28:27 Slop proxies add no value at all30:49 Aggressive nitpicking reviews35:01 Everything in software engineering is about trade-offs41:16 Racoon heist game is only fun for 1 minute 15 seconds43:46 New Year’s resolution to be more ambitious48:11 You have to learn to throw things away51:57 Features are cheap. That doesn’t mean you should build them all1:00:45 Engineering management skills are so useful1:04:44 QA specialists should be having a great time1:07:53 Writing is thinking, don’t outsource it1:08:23 Skill atrophy is a choice you make1:10:07 I believe in people who are motivated1:11:55 Systems are not set up to deal with this volume1:18:48 Research agents stopped being absolute garbage1:21:49 The whole point of the “human in the loop”1:26:10 Dream: I want there to be more small businesses

What happens when a database engineer spends 13 years on SQL Server and then starts working on Postgres? In Episode 41 of Talking Postgres, Distinguished Engineer Panagiotis “Panos” Antonopoulos of Microsoft joins Claire to share what surprised him most about making that transition. We explore why Postgres felt familiar from the start—and what shocked Panos about the clean and lean Postgres codebase. We also dig into how public mailing lists and AI can help explain why design decisions were made, why more people are asking “why not Postgres?”, and the shared-storage architecture behind Azure HorizonDB.Previously on Talking Postgres:Talking Postgres Ep 39: From MemSQL to HorizonDB, an engineer's journey with Adam ProutTalking Postgres Ep 38: How I went from Oracle to Postgres (with a big NoSQL detour) with Gwen ShapiraTalking Postgres Ep 40: How I got started running a Postgres user group with Jeremy SchneiderLinks mentioned in this episode:SIGMOD: ACM SIGMOD-PODS Conference 2027  CMUDB talk: HorizonDB: Co-Designing Postgres and Azure for Cloud-Native OLTP, by Adam ProutPostgreSQL mailing list: pgsql-hackersPostgreSQL docs: pg_stat_slru (simple least-recently-used)Docs: Azure HorizonDBPoster: Postgres Happiness Hints

Intensely local user groups have been part of Jeremy Schneider's story from the start—from Linux meetups at a Michigan coffee shop to a closet server running an Oracle database nobody knew anything about. In Episode 40 of Talking Postgres, Postgres engineer and Seattle Postgres User Group co-organizer Jeremy Schneider joins Claire to share how community led him to Postgres after 15 years with Oracle—and why "it's like I was born to be here." Plus: the newly-updated Postgres Happiness Hints poster, advice for starting your own user group, and his POSETTE 2026 talk on CloudNativePG.Previously on Talking Postgres:Talking Postgres Ep 38: How I went from Oracle to Postgres (with a big NoSQL detour) with Gwen ShapiraLinks mentioned in this episode:Seattle Postgres User Group: Meetup pageSeattle Postgres User Group: YouTube channelUser Group Map from PGConfEU 2025 talk: 48 Postgres User Groups during PG18 timeframePostgreSQL.org: Listing of local Postgres User GroupsPostgres Meetup For All (a virtual meetup): Meetup pageJeremy Schneider’s Blog: Ardent Performance ComputingPoster: Postgres Happiness HintsPGConf.dev 2026: Posters from Poster SessionPGConf.dev 2026 Poster Session: Talking Postgres posterPOSETTE: An Event for Postgres 2026: Jeremy’s POSETTE 2026 talk with Leonardo CecchiPOSETTE 2026: Livestream 3 schedule & talksOracle docs: Oracle Database Concepts PDFBook: Oracle Insights: Tales of the Oak Table

What does it take to make Postgres and Azure fit together cleanly, like puzzle pieces? In Episode 39 of Talking Postgres, Adam Prout—distinguished engineer at Microsoft and a founding architect of Azure HorizonDB—joins Claire to trace his engineering journey from MemSQL to Postgres. We dig into shared-storage architecture and how HorizonDB pushes more work into the storage layer; why the team chose Rust; and what “good systems programming” looks like when being paranoid is a feature, not a bug. Along the way: startup vs big company tradeoffs, and how working on databases exposes you to so many interesting parts of computer science.  Previously on Talking Postgres:Talking Postgres Ep29: How I got started leading database teams with Shireesh ThotaLinks mentioned in this episode:Blog post: Announcing Azure HorizonDB, by Charles Feddersen & Affan DarCMUDB talk: HorizonDB: Co-Designing Postgres and Azure for Cloud-Native OLTP, by Adam ProutResearch paper: Socrates: The New SQL Server in the CloudProduct page: Azure HorizonDBVideo of POSETTE 2025 talk: Scaling Postgres to the next level at OpenAIBlog post: Scaling PostgreSQL to power 800 million ChatGPT users, by Bohan ZhangBlog post: Supporting ChatGPT on PostgreSQL in Azure, by Affan Dar, Adam Prout, & Panagiotis Antonopoulos Docs: Azure Database for PostgreSQLGitHub repo: pgrxDiscord: PostgreSQL Hacking serverConference: PGConf.dev 2026Conference Schedule: PGConf.dev 2026 Schedule