Maintainers

PostgreSQL has no CODEOWNERS file in the repository — maintainership is governed by the project's social structure on pgsql-hackers, not by GitHub conventions. The closest the source tree comes is the file src/backend/DEVELOPERS (currently empty as a stub) and the commit history itself.

This page maps subsystems to the people who have committed most to them. The list is derived from git shortlog over the project's full history; "active contributors" are committers whose names appear in commits to the relevant directory in the past few years. Contact via pgsql-hackers, not direct messages.

Top committers (project-wide, by commit count)

Committer	Commits
Tom Lane	32,599
Bruce Momjian	16,680
Peter Eisentraut	8,509
Michael Paquier	4,613
Álvaro Herrera	3,942
Heikki Linnakangas	3,449
Robert Haas	3,302
Andres Freund	2,580
Noah Misch	1,960
Andrew Dunstan	1,866

All ten remain active.

Subsystem-to-committer mapping

This table is approximate. PostgreSQL's "owners" are the hackers most likely to have an opinion when you propose a change, derived from who has been most active in each area in recent years.

Subsystem	Recent active committers
Optimizer / planner	Tom Lane, David Rowley, Andres Freund, Robert Haas
Executor	Andres Freund, Tom Lane, Robert Haas
Parser / SQL grammar	Tom Lane, Peter Eisentraut
Catalog	Tom Lane, Peter Eisentraut, Michael Paquier
Heap / table AM	Andres Freund, Heikki Linnakangas, Peter Geoghegan
B-tree	Peter Geoghegan, Tom Lane
GIN / GiST / SP-GiST / BRIN	Heikki Linnakangas, Tomas Vondra, Alexander Korotkov, Andrey Borodin
WAL / xlog	Heikki Linnakangas, Andres Freund, Michael Paquier, Robert Haas
Buffer manager / storage	Andres Freund, Heikki Linnakangas, Thomas Munro
Async I/O (storage/aio)	Andres Freund, Thomas Munro
Lock manager	Andres Freund, Robert Haas, Tom Lane
Streaming replication	Michael Paquier, Robert Haas, Fujii Masao, Heikki Linnakangas, Bertrand Drouvot
Logical replication	Amit Kapila, Peter Smith, Hou Zhijie, Tomas Vondra, Álvaro Herrera, Masahiko Sawada
Logical decoding	Andres Freund, Tomas Vondra, Amit Kapila
Postmaster / process model	Heikki Linnakangas, Robert Haas, Andres Freund
Autovacuum / VACUUM	Peter Geoghegan, Andres Freund, Álvaro Herrera, Masahiko Sawada
Partitioning	Álvaro Herrera, Robert Haas, Amit Langote, David Rowley
Statistics (planner stats)	Tom Lane, Tomas Vondra
pgstat* / pgstat collector	Andres Freund, Michael Paquier
TOAST / compression	Andres Freund, Tom Lane, Tomas Vondra
JIT	Andres Freund
psql	Tom Lane, Peter Eisentraut, Daniel Gustafsson
pg_dump / pg_restore	Tom Lane, Stephen Frost
pg_basebackup / pg_receivewal	Robert Haas, Magnus Hagander, Daniel Gustafsson
pg_upgrade	Bruce Momjian, Peter Eisentraut, Robert Haas
pg_rewind	Heikki Linnakangas, Michael Paquier
libpq	Tom Lane, Peter Eisentraut, Daniel Gustafsson, Jacob Champion
ECPG	Michael Meskes (longtime maintainer)
PL/pgSQL	Tom Lane, Pavel Stěhule (frequent contributor)
PL/Perl	Andrew Dunstan, Alexey Kondratov
PL/Python	Peter Eisentraut
PL/Tcl	Jan Wieck (historical), Tom Lane
Build system (autoconf)	Tom Lane, Peter Eisentraut
Build system (Meson)	Andres Freund, Peter Eisentraut
TAP test framework	Michael Paquier, Andrew Dunstan, Daniel Gustafsson
Documentation	Peter Eisentraut, Tom Lane, Bruce Momjian
Translation infrastructure	Peter Eisentraut, Álvaro Herrera (Spanish)

(This is an editorial reconstruction, not a formal ownership list. The authoritative answer to "who should I CC on this patch?" is git log <path> over the past year or two.)

How to find the right people for a patch

1. Read the commit history of the file or directory you're changing. git log --since="2 years ago" -- <path> shows recent committers.
2. Search the mailing list archives for the subsystem name. Threads on pgsql-hackers are the gold standard for "who has had recent opinions about this."
3. Post your patch to pgsql-hackers and register it in the commitfest. If specific people are a natural fit for review, CC them. Otherwise the commitfest manager and self-assigning reviewers will route it.
4. Don't email committers directly about pending patches. Discussion happens in public.

Bus factor and review

PostgreSQL's review process is unusually robust. Even features championed by the most prolific committers go through public review. The flip side is that the project has a relatively small set of committers (the people who can actually push) and so commit attribution is concentrated. New committers are added every few years after sustained contribution and review work.

The project has elected a pgsql-hackers rhythm where review is the bottleneck more often than coding. Any contributor wishing to get a feature in is best advised to also review other people's patches; the karma economy works.

For the social process more broadly, see the Developer FAQ on the project wiki.