Ten Postgres Hacker Journeys—and what they teach us

Slides from a conference talk at PGConf NYC 2025. Abstract: When I first got into software engineering, I thought studying history was a waste of time. I’ve since learned that understanding how people got where they are—and what they learned along the way—is one of the fastest ways to level up.

In that spirit of standing on the shoulders of those who came before us, this talk shares lessons from 10 Postgres major contributors about how they became effective Postgres hackers. But the talk isn’t just for contributors. Whether you’re an app developer, DBA, data engineer, someone who’s thinking about becoming a contributor, or just someone who uses Postgres every day, you’ll find takeaways here.

This is an updated version of an illustrated talk I gave at PGConf.dev 2025. You’ll hear how these contributors first got involved, where they turned to build their database knowledge, how they learned through code, and—maybe most importantly—the invisible curriculum they had to navigate along the way. This version includes a few new stories, deeper dives, and more time to explore the not-often-discussed skills, habits, and mindset shifts that helped them grow.

Even if you never plan to contribute to Postgres, these hacker stories pull back the curtain on how a handful of PG contributors got their start—and what they picked up along the way. Whether you’re early in your career or deep into it, these stories give us all something to think about.

Transcript

1. Ten Postgres Hacker Journeys— and what they teach us CLAIRE GIORDANO @clairegiordano.bsky.social • @TalkingPostgres.com • @PosetteConf.com
2. @clairegiordano @clairegiordano.bsky.social Developer Eng Manager PM Marketer Writer Open-source champ Community Lead Podcaster POSETTE: An Event for Postgres PGCA
3. Quite a lot of Postgres work @ Microsoft 3 3 aka.ms/blog-pg-at-microsoft
4. Quite a lot of Postgres work @ Microsoft 4 4 aka.ms/blog-pg-at-microsoft
5. Used to think the study of History was a waste of time Photo by Claire Giordano, Sep 2024
6. One of the things I get to do as part of my Postgres community work Host & co-produce a monthly podcast
7. 40 guests & 31 episodes of Talking Postgres Listen wherever you get your podcasts—or on TalkingPostgres.com
8. These 10 PostgreSQL hackers have been guests on the podcast Melanie Plageman Heikki Linnakangas Tom Lane Robert Haas Bruce Momjian Daniel Gustafsson David Rowley Andres Freund Thomas Munro Álvaro Herrera
9. In the spirit of standing on the shoulders of those who’ve come before
10. @clairegiordano App Developer This talk is NOT JUST for Postgres contributors! DBA Data Engineer Someone thinking about becoming a Postgres contributor Someone who uses Postgres every day
11. caveats The content has
12. Caveat #1 I abbreviated some of the direct quotes But I did not alter the meaning of the quotes!
13. Caveat #2 More learnings to come in future! Lots of future podcast guests with different experiences & learnings to share. People are different. YMMV
14. Catalyst(s) Knowledge Inputs Learning thru Code Invisible Curriculum 4 forces that shaped these 10 PostgreSQL hackers @clairegiordano
15. Catalyst(s) Knowledge Inputs Learning thru Code Invisible Curriculum What were some of the Catalysts? @clairegiordano
16. Everybody’s catalyst is unique So many different origin stories So many different triggers Catalyst(s)
17. 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)
18. 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)
19. Where is this? 19 Catalyst(s)
20. Daniel Gustafsson went to Copenhagen Catalyst(s)
21. “ 21 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.”
22. 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)
23. 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 23 Catalyst(s)
24. But these Catalysts were NOT just about “luck” About being willing to say “YES” when the opportunity came along Catalyst(s)
25. Catalyst(s) Knowledge Inputs Learning thru Code Invisible Curriculum What Knowledge was ingested? @clairegiordano
26. 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
27. 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
28. 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
29. Catalyst(s) Knowledge Inputs Learning thru Code Invisible Curriculum Examples of Learning through Code? @clairegiordano
30. “ 30 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
31. 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
32. 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
33. 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
34. “ 34 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
35. “ 35 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.”
36. Catalyst(s) Knowledge Inputs Learning thru Code Invisible Curriculum What is the Invisible Curriculum? @clairegiordano
37. 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
38. 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
39. “ 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...”
40. 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
41. “ 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
42. 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
43. 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
44. Failures = extremely public in Open Source “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
45. 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
46. 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
47. Meet people in person when you can “But the week or two after the conference, all of a sudden our community was much more active. What I realized was that people I had lunch with at the conference were now active in the community. And I started to understand that the personal touch of spending time with people and having lunch with them is a really key part of motivating. Email only can go so far. Zoom calls only go so far.” Invisible Curriculum —Bruce Momjian, Ep26 of Talking Postgres
48. “ Invisible Curriculum Embrace edit cycle & don’t wait for the “perfect patch” Source: Talking Postgres Episode 20: How I got started as a developer (& in Postgres) I wrote a quick hack that was by no means meant to be committed and put that up on a list just to say, what do you think about doing something like this? And it's been through three or four iterations now and still not committed. I think this sort of development process works well: share something early and improve it over time— rather than expecting you can show up out of nowhere with a perfect patch.” Tom Lane
49. Be willing to explore dead-ends “I think it's impossible to do a project of the complexity of AIO without exploring dead ends. Because, otherwise, one wouldn't have been ambitious enough to find the actual right design— and would have just gotten stuck in some local minimum of okay-ish design.” —Andres Freund, Ep31 of Talking Postgres Invisible Curriculum
50. “ 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 Herrera
51. “ 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 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
52. Recognize other people’s work! “So if your motivation is to help people feel valued and show them what they've done has made a difference—that's a ZERO COST thing to do. It can be humbling to do it because you're highlighting someone else. And I think some people chafe at that—or they feel they're demeaning themselves by highlighting other people—but it is an incredibly good motivator .” Invisible Curriculum —Bruce Momjian, Ep26 of Talking Postgres
53. Remember to take care of yourself “I found that development progress definitely was associated with how well I was doing in my personal life, and exercise, and all that kind of stuff. Particularly for long projects: it's important to take care of yourself and not just invest into the project and do more and more hacking.” —Andres Freund, Ep31 of Talking Postgres Invisible Curriculum
54. Catalyst(s) Knowledge Inputs Learning thru Code Invisible Curriculum Lessons from PostgreSQL Hacker Stories ⑉ 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 ⑉ Embrace edit cycle ⑉ Explore dead-ends ⑉ Make work stand out ⑉ User pain points ⑉ In-person interaction ⑉ Showing gratitude ⑉ Take care of yourself @clairegiordano
55. Quotes from Episodes on: TalkingPostgres.com Ep03: Why giving talks at Postgres conferences matters with Álvaro Herrera & Boriss Mejías Ep04: How I got started as a developer (& in Postgres) with Melanie Plageman & Thomas Munro Ep08: How I got started as a developer (& in Postgres) w/ Andres Freund & Heikki Linnakangas Ep18: How I got started as a developer (& in Postgres) with David Rowley Ep19: Becoming a Postgres committer with Melanie Plageman Ep20: How I got started as a developer (& in Postgres) with Tom Lane Ep23: How I got started as a developer (& in Postgres) with Daniel Gustafsson Ep24: Why mentor Postgres developers with Robert Haas Ep26: Open Source Leadership with Bruce Momjian Ep31: What went wrong (& what went right) with AIO with Andres Freund
56. People to thank for inspiration &or reviews Álvaro Herrera Andres Freund Boriss Mejías Daniel Gustafsson David Rowley Heikki Linnakangas Melanie Plageman Robert Haas Thomas Munro Tom Lane Aaron Wislang Affan Dar Bruce Momjian My Nguyen Isaac Alves Pino de Candia Charles Feddersen
57. 57 Favor to ask you!
58. aka.ms/survey-pgconf-nyc-2025 on some of my Postgres work
59. @clairegiordano @clairegiordano@hachyderm.io TalkingPostgres.com z PosetteConf.com z linkedin.com/in/claireg @clairegiordano.bsky.social