PostgreSQL's contributor recognition includes work beyond commits
October's announcement recognizes seven contributors and promotes four to Major Contributor status. The distinction matters because maintaining PostgreSQL involves work that a commit count cannot describe.
A database project's release notes can name the authors of a new feature without describing all the work that keeps the project usable. PostgreSQL's October 17 contributor announcement recognizes substantial, long-term contributions to both its community and its codebase. Its emphasis on sustained effort is relevant to anyone who depends on the database beyond a single release.
The seven newly recognized contributors are Andrew Kane, Andy Fan, Hans-Jürgen Schönig, Jian He, Marco Nenciarini, Michael Goldberg and Sarah Conway. The project also promotes Andrey Borodin, Jacob Champion, Jelte Fennema-Nio and Robert Treat to Major Contributor status. Their promotion recognizes sustained positive impact over many years, according to the announcement.
I have run PostgreSQL in production for decades and still choose it by default for relational work. That preference depends on continuing maintenance as well as new capabilities. Recognition of long-term contribution makes some of that dependence visible without reducing it to the person whose name appears on a particular commit.
Recognition and repository authority describe different things
The committers page explicitly distinguishes people with repository push access from the broader contributor profiles. It also cautions that the ordering of committers does not represent depth of contribution. A recognition category therefore should not be read as a direct description of who can commit a patch.
The same page explains a complication in using the commit log as a measure of authorship. The author and committer fields can both identify the person who committed a patch, while the message credits the actual author and other participants. Reviewers and people who contributed ideas may also appear in the message.
This means that a mechanical count can answer a narrower question than its label suggests. Counting author fields measures what those fields contain. It does not automatically count original authors, review effort or the work needed to prepare an accepted patch. The project's own explanation is a reason to read the associated discussion and credit, rather than assigning a complete contribution history from those fields alone.
A release supplies concrete examples of shared work
The PostgreSQL 18 release notes, published in September, show several of October's recognized people in specific changes. They credit Andrey Borodin for UUIDv7 generation. Jacob Champion shares credit for OAuth authentication with Daniel Gustafsson and Thomas Munro. Jian He appears among contributors to virtual generated columns.
The release-tag version of those notes also credits Jacob Champion and Jelte Fennema-Nio for PQfullProtocolVersion(). The notes describe the function as reporting the full protocol version, including its minor component. These are attributable changes in a release already available today, rather than an attempt to infer individual accomplishments from the recognition category alone.
Shared credit is useful evidence about the work's structure. A feature can have several contributors, and one contributor can participate in changes across different parts of the system. A single headline does not identify every responsibility involved in implementation or review. The notes supply specific associations while the October announcement recognizes a longer period of contribution.
The project distinguishes its operating responsibilities
The governance directory separates policy, infrastructure and security responsibilities. It identifies the core team as the central arbiter of project policy and governance, while the sysadmin team runs project infrastructure. The security team handles vulnerability reporting and fixes related to PostgreSQL and closely related projects.
Those responsibilities help explain why community work belongs beside code work in the announcement. A public release depends on services and processes through which people can obtain software, discuss changes and report defects. Recognizing the people who sustain a project is broader than assigning ownership of its executable code.
This does not mean every contributor performs every role. The directory provides distinct descriptions precisely because the responsibilities differ. It gives users a way to understand which group handles a particular kind of project work without interpreting a recognition title as universal authority.
The terminology is being made more specific
October's announcement also says the label Contributor will become Significant Contributor on the contributor profiles page. Major Contributor will retain its name. At the time of the announcement, the change is described as underway.
That clarification matters because contributing to PostgreSQL and holding a listed recognition category are different claims. The general act of contributing includes people beyond a curated page. A more specific label can distinguish the formal recognition without implying that everybody else has failed to contribute.
I find that distinction appropriate for a project whose extension interface and documented behavior have supported so much relational work. Its durability depends on people continuing to improve and maintain it. The announcement provides named recognition for that sustained effort, while release notes and patch discussions remain the sources for understanding particular technical contributions.