What 10 Postgres Major Contributors Did to Become a Hacker | Claire Giordano | PGConf.dev 2025

Slides from a conference talk at PGConf.dev 2025 in Montréal, Canada. Abstract: There are several popular Postgres developer workshops that are useful for new Postgres contributors looking to skill up: workshops like “Intro to Hacking on Postgres” and “Patch Review Workshop”. And then there is the new mentoring program spearheaded by Robert Haas. But what about before a developer is ready to roll up their sleeves and start contributing to Postgres. Are there useful, foundational things for developers to learn before joining the Postgres project?

In this illustrated talk, you'll get insights from 10 Postgres major contributors about what they learned on their journey to becoming hackers—lessons they say were instrumental in helping them contribute effectively to Postgres. You'll discover the catalysts that first got them involved, where they turned to build their database knowledge, how they learned through code, and—perhaps most importantly—the invisible curriculum they had to navigate along the way.

Transcript

1. CLAIRE GIORDANO @clairegiordano.bsky.social • @TalkingPostgres.com • @PosetteConf.com What 10 Postgres Major Contributors Did to Become a Hacker
2. @clairegiordano @clairegiordano.bsky.social Engineer Dev Manager PM Marketer Writer Open-source champion Community Lead Podcaster POSETTE: An Event for Postgres
3. Quite a lot of Postgres work @ Microsoft 3 3 aka.ms/blog-pg-at-microsoft
4. Learnings & insights from podcast conversations
6. 6 2caveats
7. #2: Focus is on these 10 Postgres major contributors All guests on podcast All hackers
8. So story is not over yet! Lots of other Postgres major contributors with different experiences & learnings to share. People are different. YMMV
9. Catalyst(s) Knowledge Inputs Learning thru Code Invisible Curriculum 4 forces that shaped these 10 PostgreSQL hackers @clairegiordano
10. Catalyst(s) Knowledge Inputs Learning thru Code Invisible Curriculum What were some of the Catalysts? @clairegiordano
11. Everybody’s catalyst is unique So many different origin stories So many different triggers Catalyst(s)
12. MySQL meltdown led to Postgres “We used MySQL. And there was a particular moment where we got some coverage, our website was mentioned on some US TV or radio program. And we got a lot of hits—and our system completely melted down.” —Thomas Munro, Ep04 of Talking Postgres Catalyst(s)
13. Paternity leave & a baby that sleeps “I was actually on paternity leave with my second child and she was a good sleeper. That was a very easy time, but I had a couple of months of feeding the baby and then watching her sleep. And I had a lot of spare time on my hands. So I started to look around for open source projects to work on...” —Heikki Linnakangas, Ep08 of Talking Postgres Catalyst(s)
14. Where is this? 14 Catalyst(s)
15. Alt-title: Daniel meets Bruce. Circa ~2005 Catalyst(s)
16. “ 16 Source: Talking Postgres Episode 23: How I got started as a developer & in Postgres Catalyst(s) Daniel Gustafsson “I can’t explain why I went there…” I was attending a conference in Copenhagen. I was very interested in operating systems at the time. I was there to listen to Robert Watson from FreeBSD. That was the reason I went. Bruce Momjian had a session at 3 p.m. I don't know why I went to that session over the other ones that were going at the same time. I can't explain why I went there. But I'm very glad I did. Because I sat down. And Bruce Momjian was going over all the capabilities of Postgres. And I was sitting there, being completely blown away.”
17. Getting nudged by a professor “The professor who was teaching it pulled me aside and said, you really ought to go apply to be a research assistant in the department because you're good at this. And so I said, okay, because I needed a part-time job and that sounded way better than flipping burgers.” —Tom Lane, Ep20 of Talking Postgres Catalyst(s)
18. Would be unemployed if not for mentorship? “I think I would still be unemployed if it weren't for mentorship.” ~~~ “I happened to get a job where I could work on Postgres code and then have hundreds and hundreds of hours of other people's time mentoring me.” —Melanie Plageman, Ep19 of Talking Postgres 18 Catalyst(s)
19. Almost called this category Serendipity But it wasn’t just about luck About being willing to say “YES” when the opportunity came along Catalyst(s)
21. 21 Robert Haas Shout-out to new PG mentoring program inspired partly by conversations @ PGConf.dev 2024 in Vancouver FROM ROBERT HAAS BLOG Catalyst(s)
22. Catalyst(s) Knowledge Inputs Learning thru Code Invisible Curriculum What Knowledge was ingested? @clairegiordano
23. The Dragon Book a.k.a. Compilers: Principles, Techniques, and Tools Books! Knowledge Inputs Melanie Plageman Daniel Gustafsson David Rowley From Nand to Tetris The Art of SQL The Purple Book a.k.a. Structure and Interpretation of Computer Programs The Practice of Programming
24. Mailing lists! Entire 9.1 Manual “I had a laptop with me and I did spend quite a lot of time reading the Postgres mailing lists. I also remember reading the entire manual, I think, for Postgres 9.1. I was traveling by myself in Australia and quite often I was maybe in a very remote part of the desert. And in the evenings, quite often there wasn't a great deal of things to do. So I ended up just doing a lot of reading .” —David Rowley, Ep18 of Talking Postgres Knowledge Inputs
25. Every. Andy. Pavlo. Lecture. Ever. “I took classes at CMU and I listened to every Andy Pavlo lecture ever.” —Melanie Plageman, Ep19 of Talking Postgres Knowledge Inputs
26. Catalyst(s) Knowledge Inputs Learning thru Code Invisible Curriculum Examples of Learning through Code? @clairegiordano
27. “ 27 Source: Talking Postgres Episode 18: How I got started as a developer (& in Postgres) David Rowley Wrote a channel service bot for IRC I wrote a channel service bot for IRC. And I picked C to do that. My initial choice was C++. But for some reason, quite early on, I couldn't figure out how to link to C++ files together once they're compiled. I decided to use the opportunity to switch to C. So in my spare time, I was working on that. And I spent about a year working on this project. And that's what really got me into algorithms like data structures and things in C. I learned a huge amount there, like hash tables and binary search trees.” Learning thru Code
28. Some things never change “Because you were looking at, potentially a lot of data processing, a lot of lookups that needed to be fast. The IRC network wasn't that big, but I just wanted to make this fast. —David Rowley, Ep18
29. Tried to write 2 relational databases “I was a consultant in law firms at that time. I was using relational databases for my work, and I was always curious how the internals of those databases worked. So over the next few years, in the early 90s, I believe I actually tried to write two relational databases from scratch. Got into trouble with bootstrapping and basically gave up. But in 1996…” —Bruce Momjian, Ep26 of Talking Postgres Learning thru Code
30. Went down a bugfixing rabbithole “The first thing I had to fix: there was a port to HP-UX, but when we tried to use it, we found a few bugs. And so I had to send in patches for that. Next: We wanted to use the listen and notify commands to send signals between machines doing the trading ... So I had to go fix them… And gradually, I got sucked down this rabbit hole... —Tom Lane, Ep20 of Talking Postgres Learning thru Code
31. “ 31 Source: Talking Postgres Episode 04: How I got started as a developer (& in Postgres) So I wrote a Postgres extension At the time I was trying to figure out how do I make FORMAT do the thing I want—or do I need to use another piece of software with it. And someone told me that Postgres has this extensibility thing and you can write extensions and they can access internal Postgres code and do cool things with it if you write them in C. So, I wrote this extension that basically was a souped- up FORMAT function that lets you interpolate. And I thought it was so cool you could do that.” Learning thru Code Melanie Plageman
32. “ 32 Source: Talking Postgres Episode 24: Why mentor Postgres developers? Robert Haas Got involved in patch reviews The 2nd thing I did is start getting involved in patch reviews. And the question I tried to ask myself as I started reviewing a patch: ”What is Tom going to say about this patch?" And could I say the thing that Tom is going to say before Tom says it? So by the time Tom sees the patch, some of these things have been improved...” Learning thru Code Reviewing patches for me was a helpful way of getting my feet wet because it allowed me to look at a lot of different areas of the source code & start to become familiar with things.”
33. Catalyst(s) Knowledge Inputs Learning thru Code Invisible Curriculum What is the Invisible Curriculum? @clairegiordano
34. Invisible Curriculum involves a state change inside of you Taming your ego Taking feedback Managing emotions Striving for excellence Adjusting tone of voice Empathy for users Invisible Curriculum
35. Maybe caterpillar is better metaphor for ”state change”? Taming your ego Taking feedback Managing emotions Striving for excellence Adjusting tone of voice Empathy for users Invisible Curriculum
36. “ Invisible Curriculum Take feedback (& don’t take it personally) Source: Talking Postgres Episode 19: Becoming a Postgres committer My perception is that taking feedback is the most important thing that you can do—and demonstrate that you can do—in any role.” Melanie Plageman “ When you're getting feedback, it's not necessarily about whether or not you're good at engineering—or your patch is a good patch. It's about whether or not it's the right thing for Postgres. Not taking things personally— and thinking about it more from the perspective of ‘how can I make my work a better fit for Postgres’—makes it hurt a little bit less...”
37. Adopt mindset that embraces feedback “You have to understand: everybody wants to make things better. If they comment on your patch & say, "Why don't you do it like this?”, they're hoping to get to a better spot. And you ought to respond in that spirit. So it's a mindset you have to adopt that you're looking for ways to improve Postgres—& some of your ideas will be good, some will be bad, & some maybe will get to be good with some tweaking.” Invisible Curriculum —Tom Lane, Ep20 of Talking Postgres
38. “ Invisible Curriculum Accept that patch review changes things Source: Talking Postgres Episode 08: How I got started as a developer (& in Postgres) The thing that happened—that happens to a lot of people who write their first patch to Postgres—is that when Tom Lane committed it, the patch that was committed didn't look very much like the patch I actually submitted. But I was glad about that anyway. I'm proud of the first patches.” Heikki Linnakangas
39. Patches contain ideas of dozens of people “When you step back, you realize the Postgres project, or even a single patch, is not really the product of one person. It's the ideas of dozens of people all being merged together. And the patch author may create the initial version—but by the time that version is finally applied, a good patch will have the ideas of dozens of people inside.” Invisible Curriculum —Bruce Momjian, Ep26 of Talking Postgres
40. Push through the ups & the downs “There's just a huge amount of human interaction [in patch review]—and a huge amount of expectation and disappointment. Sometimes things don't go in for a whole year or two. Or sometimes things are outright rejected, sometimes things just don't work out. There's a lot of processes & pain & emotions involved.” —Thomas Munro, Ep04 of Talking Postgres Invisible Curriculum
41. Your failures will be extremely public “One of the interesting things about working in open source is that your failures are inherently extremely public. You can't look the other way and pretend it didn't happen because there it is in the commit log. Anybody can see and you just have to own up to it and deal with it.” —Tom Lane, Ep20 of Talking Postgres Invisible Curriculum
42. Adapt your language to the audience “My technical German is much more blunt than English and I had a lot of conflicts in the early years that turned out to be just me not understanding that I can't translate everything literally. The number of conflicts I had just reduced drastically after [adapting] and it made it much easier to collaborate.” —Andres Freund, Ep08 of Talking Postgres Invisible Curriculum
43. Make your work stand out “Try and make your work stand out. Try and prove that you've done the research and you've looked at the archives and you've done all your homework. I think when people come and they've done all their homework and due diligence, I think it's just easier.” —David Rowley, Ep18 of Talking Postgres Invisible Curriculum
44. “ Invisible Curriculum Seeing user problems gives you an edge Source: Talking Postgres Episode 08: How I got started as a developer (& in Postgres) One of the reasons that I was able to succeed was that I was consulting around Postgres. So I was seeing a lot of problems that people had with Postgres when used in anger. And that allowed me to see people the problems that other Postgres developers didn't see, which then provided a niche for me to work on where I had a small advantage over others—because I was still seeing all those day-to-day problems.” Andres Freund
45. “ Invisible Curriculum User feedback can help you prioritize Source: Talking Postgres Episode 03: Why give talks at Postgres conferences When I was working for 2ndQuadrant, I mean before the acquisition, I had plenty of involvement with customers. In professional services like Boriss. And that was a very productive mechanism to know what Postgres features to work on.” Álvaro Herrerra
46. Catalyst(s) Knowledge Inputs Learning thru Code Invisible Curriculum Becoming a Hacker is a Process, not a moment ⑉ Meltdown ⑉ Paternity leave ⑉ Attending a 3pm talk ⑉ Nudged by professor ⑉ Mentoring ⑉ Books ⑉ Mailing lists ⑉ Manual ⑉ Pavlo lectures ⑉ Wrote a bot ⑉ Wrote 2 databases ⑉ Bugfixing ⑉ Wrote extension ⑉ Patch review ⑉ Feedback ⑉ Ups & downs ⑉ Working in public ⑉ Language ⑉ Homework ⑉ User pain points @clairegiordano
47. People to thank for inspiration &or reviews Álvaro Herrera Andres Freund Bruce Momjian Daniel Gustafsson David Rowley Heikki Linnakangas Melanie Plageman Robert Haas Thomas Munro Tom Lane Aaron Wislang Affan Dar My Nguyen Pino de Candia Charles Feddersen
48. 48 Favors to ask you! 2
49. A free & virtual developer event KEYNOTE: Databases in the AI Trenches Bruce Momjian Incrementing Backup in PostgreSQL Robert Haas Performance Archaeology – 20 years of improvements Tomas Vondra Best Practices for Tuning Slow Postgres Queries Lukas Fittl What’s new in the Postgres 18 query planner / optimizer David Rowley pg_duckdb: Ducking awesome analytics in Postgres Jelte Fennema-Nio Neon: How we made PostgreSQL serverless Heikki Linnakangas Debugging Data Corruption in PostgreSQL: A Systemic Approach Palak Chaturvedi Nitin Jadhav Logical replication theory and concepts Ashutosh Bapat What is Patroni, really? Polina Bungina Managing Postgres at scale: Challenges, Tools & Techniques Karen Jex Myths and Truths about Synchronous Replication in PostgreSQL Alexander Kukushkin Building a PostgreSQL data warehouse Marco Slot Leveraging table partitioning for query performance and data archiving Derk van Veen Hacking Postgres Executor For Performance Amit Langote Resource Control Admission: I have a date with my PSI Cédric Villemain Designing a monitoring feature in PostgreSQL Rahila Syed
50. @clairegiordano @clairegiordano@hachyderm.io TalkingPostgres.com z PosetteConf.com z linkedin.com/in/claireg @clairegiordano.bsky.social