Analysis: PostgreSQL Hacker Mentoring Program 2026 — Call for Applications
Overview
This thread documents the third year of Robert Haas's 1:1 hacker mentoring program, which pairs aspiring PostgreSQL developers with existing committers. While not a technical patch discussion, this thread is architecturally significant to the PostgreSQL project's sustainability — it represents the formalized pipeline for developing future committers who will maintain and evolve PostgreSQL's internals.
The Core Problem: Committer Pipeline Sustainability
PostgreSQL's development model relies on a relatively small pool of committers (roughly 25-30 active) who gate all changes to the codebase. The project's long-term health depends on growing this pool with developers who deeply understand PostgreSQL internals — the optimizer, executor, WAL subsystem, storage engine, MVCC, buffer management, replication, and catalog systems. These are complex, interdependent subsystems where expertise takes years to develop.
The mentoring program addresses a structural challenge: the gap between "active contributor submitting patches" and "committer trusted to review and commit others' work" is enormous and historically has been bridged only through years of self-directed effort with informal guidance. Formalizing this process reduces the bus factor for critical subsystems and ensures institutional knowledge transfer.
Program Statistics and Health Metrics
Year 1 (2024-2025)
- ~50% of mentor-mentee relationships succeeded
- Several mentors declined to continue
- Robert Haas characterized this as "slightly disappointing"
Year 2 (2025-2026)
- ~75% success rate for ongoing relationships
- 10-12 active mentees paired with 9-10 committers
- Fuzzy numbers indicate some relationships are in transition states
- Multiple existing mentors expressed willingness to take additional mentees
Year 3 Intake (2026)
- 23 applications received
- 7 people matched with committer-mentors (~30% acceptance rate)
- The low match rate reflects both limited mentor capacity and the program's selectivity
Key Design Decisions and Observations
Selection Criteria
The program explicitly targets developers who are:
- Already active on pgsql-hackers — not newcomers seeking introduction
- Committed to significant future hacking time — this filters for seriousness
- Potentially on a committer track — the ultimate goal is growing the committer pool
Matching Philosophy
Robert Haas emphasizes overlap in working areas as the strongest predictor of success. This makes architectural sense: a mentor working on the optimizer cannot effectively guide someone focused on logical replication, because the review cycles, patch context, and design judgment needed are domain-specific.
Program Governance
- Single coordinator (Robert Haas) handles all matching
- Application information shared with potential mentors (with private communication channel for sensitive details)
- Fixed application window (roughly mid-February to mid-March)
- Results communicated individually rather than publicly
Implications for PostgreSQL Development
The 7 new mentees joining in 2026, combined with the ~10-12 continuing from prior years, means roughly 17-19 developers are in some stage of committer-track mentoring. Given PostgreSQL's committer pool size, this represents a meaningful investment in future capacity.
The 30% acceptance rate (7/23) and the note that those not already active are less likely to be matched suggests the bottleneck is mentor availability, not applicant quality. With 9-10 committers mentoring, this represents roughly one-third of active committers participating — a substantial community commitment.
Structural Observations
The improving success rate (50% → 75%) between years one and two suggests the program is developing better matching heuristics and setting better expectations. The fact that some mentors declined to continue after year one but the program still grew indicates successful recruitment of replacement mentors.
The use of Google Forms for intake and the March 15 deadline creates a structured cohort model rather than rolling admission, which likely reduces coordination overhead and allows batch-matching optimization.