PostgreSQL Commitfest Metrics: PGConf.dev 2026 Part One

Obviously I would have liked to post this closer to the event, but life got in the way. The talk was in May and the recording has been up for a while, so here we go:

PGConf.dev 2026 took place from May 19th to 22nd, 2026, at Simon Fraser University's Harbour Centre campus in downtown Vancouver, BC, Canada. It was my first one, and I had been meaning to go for years.

If you're familiar with other large Postgres events like PGConf.EU or PostgreSQL@SCaLE, PGConf.dev is a different beast. It is the PostgreSQL development conference, and the whole event is arranged around the work rather than around an audience. An in-person commitfest ran in one of the rooms on the Wednesday and Thursday, so patches were being reviewed in the building while the talks were going on. There were community office hours. The Friday was dedicated entirely to the unconference, with the schedule built on the day from whatever the attendees proposed.

For anyone who wants to get their hands dirty and get closely involved in the project, this is the conference to go to. You are in a room with the people who write and commit the code, and the barrier to walking up and asking them something is about zero. I cannot recommend it highly enough.

The talk: PostgreSQL Commitfest Metrics

On the Wednesday afternoon I presented "PostgreSQL Commitfest Metrics: A Quantitative Analysis" together with Andreas "ads" Scherbaum (EDB). We had been pulling data out of the Commitfest application, and spent a while working out what it says about what happens to a patch after somebody sends it in.

Because this is the sort of subject that is easy to misread, we opened by saying what the talk was not. It is not a critique of any contributor, it is not a critique of any committer, and it is not a claim that anything is broken. It is an observation rather than a diagnosis, and we deliberately stopped short of recommending any fixes. What we wanted was to put the numbers on the table and let the project examine them.

We looked at 58 commitfests, 6,678 patches and 899 authors, from December 2014 to April 2026. We used medians and percentiles throughout rather than averages, because a handful of very old patches can drag an average down to where the data is skewed.

There are four indicative numbers we really need to look at:

• 42.6% of authors only submitted exactly one patch
• 35.2% of patches were never committed (returned-with-feedback, withdrawn, rejected, rolling-over)
• 46 patches have been stuck for two years or more
• One patch has been open for 3,750 days (over 10 years – not committed, rejected or withdrawn)

Of the patches that do get committed, the median takes 80 days from submission. The 90th percentile is 256 days and the 99th is 711.

Volume up, committer pool flat

The single most useful chart we produced is this one, because it explains a lot of the rest without anybody having to argue about it.

Patches and authors roughly doubled over ten years. The number of committers did not move.

In 2015 there were 418 patches from 125 authors. In 2025 there were 885 patches from 272 authors. Both metrics roughly doubled, which is what you generally want to see in a healthy project. What did not double is the number of people who can merge the result: 38 distinct committers appear across the whole twelve years, and the median number actually committing in a given year is 26.5. The dotted line at the bottom of the chart is flat by construction.

That is not a complaint about committers: they volunteer their highly specialised attention and time. It's plain maths: if the incoming (patch) side doubles and the outgoing (merge) side does not, something has to absorb the difference. What absorbs it is waiting time.

Do first-time authors come back?

This is the number I find the hardest to look at.

Of the people who sent a first patch in 2015, 73% sent another one later. For 2024 it is 37%.

There is no cliff, which somehow makes it worse: it shows a steady decline over the past decade. 2015 was 73%, 2017 was 55%, 2019 was 48%, and 2023 and 2024 have settled around 36-37%. 2025 and 2026 are too recent to call, since "did they come back" needs time to show.

Put that next to the first of the four numbers and you get the picture: 42.6% of everyone who has ever appeared as a patch author in a commitfest appeared exactly once. Meanwhile the top five committers account for 55% of commits and the top ten for 74%, so the work is concentrated at both ends.

Where the waiting actually happens

My initial assumption was that the bottleneck would be at the end of the pipeline, with patches marked Ready for Committer piling up waiting for somebody senior to press the button. The data says otherwise: At measurement time, 54 patches were Ready for Committer, and the median time spent in that state was 3 days. The 90th percentile was 30 days. Patches that reach the front of the queue are, on the whole, dealt with promptly.

The waiting happens earlier.

196 of the 331 active patches had no reviewer signed up at all.

Of 331 active patches, 196 of them, or 59.2%, had nobody signed up to review. The median wait for those was 54 days, the 90th percentile 244 days, and the oldest had been sitting there for 892 days. Across the whole history, 72.1% of patches in "Needs review" had no reviewer assigned, and of the patches that did get a reviewer, 72% got exactly one.

So it is not that patches are queuing for a committer. It is that a majority of them never reach a state where a committer would look at them, because nobody picked them up in the first place. That is a much more tractable problem, and it is also the one a newcomer runs into first.

What we could not measure

The caveat, and we spent a slide on it because it matters: the Commitfest application does not see everything and, unfortunately, it looks like it does not see most things.

• Only about 17% of git commits (2021-2026) appear in any commitfest
• ~80% of patches are only on pgsql-hackers, so mailing list review is not in the data
• There's no cross-reference between commit ID, mailing list thread and commitfest entry so no audit trail

Commitfest is not a patch tracker, and it was not a CI interface either, at least not initially: it dates from 2014, CFBot from around 2018, and the two were only integrated around 2025.

Our reading, and the main question

What we said on the day is that the data is consistent with a process under strain. Patch volume has doubled, the number of committers is flat, patches roll forward from one commitfest to the next. The tracker also has no closure path short of formal rejection, which is how you end up with a ten-year-old patch.

Regarding other open source projects: Django pays two Software Foundation Fellows to triage and review as an actual job. Rust put real effort into onboarding, with a compiler that is friendly to newcomers and tells you how to fix your error, plus governance teams and an RFC process. Linux split the work across a couple of thousand MAINTAINERS entries, with different maintainers, reviewers and committers per subsystem. Perl is the cautionary tale, where cultural drift cost the project the next generation of developers, who went to Python instead. None of this applies cleanly across the PostgreSQL project, but they should serve as food for thought.

We finished with the question we set out to ask: what changes would improve the contributor experience, lower the barriers, and attract new contributors, without compromising our standards for technical excellence? Our modest suggestions would focus around making formal closure easier to issue and to receive, making reviewer routing explicit, and treating triage as a named task rather than something that happens if somebody feels like it. Yours may well be better.

Watch the talk

🎞️ Video on YouTube: youtube.com/watch?v=VIdS4EysNXI

📊 View the slides: PostgreSQL Commitfest Metrics: A Quantitative Analysis (PDF)

Many thanks to Andreas for the collaboration, and to the PGConf.dev organisers for a conference that does something no other Postgres event does. If you care, and you ever get the chance to go, take it

We put the question to the room in Vancouver, but we're still looking for more opinions around this. If you have one, or you read these numbers differently than we did, please do reach out on Mastodon at @vyruss@fosstodon.org or Bluesky at @vyruss.org.