PGConf.dev 2025 Community Summit

PGConf.dev 2025 Community Summit took place in Montreal, Canada, as part of PostgreSQL Development Conference 2025 (PGConf.dev 2025).

Groups and Topics

1. Recognizing, encouraging, and retaining contributors of all types
2. Application Developer/Engineer Outreach
3. Improving processes or infrastructure/resources
4. Supporting/Increasing/Driving diversity in the PG community
5. Recruiting new hackers, devs, & community contributors
6. Event planning
7. Outreach to Academia
8. Bugtracker (on popular demand)

Please create a section for your group and document your results.

Notes

Application Developer/Engineer Outreach

Why did we want to discuss this topic?

1. Most application developers know nothing about databases, SQL, and Postgres in particular. They lack knowledge of schema design and writing efficient queries.

2. The most frequent application developers' complaint is that database developers/DBAs are slow in making changes/responding to their requests and having trouble fitting into the Agile process.

Discussion:

There are objective reasons for that disconnect:

1. There are very few database courses in colleges, 2. Database changes can't be instantaneously implemented, and they are irreversible for the most part 3. Lack of development tools

How can we improve the situation? Mostly by talking to each other, aka outreach

1. Submitting talks to developers' conferences: Django, Python, Java, etc

2. Attending dev conferences, participating in discussions

3. Attending developers' meetups

4. Advocating for Postgres education

Outreach to Academia

• Problem statement:
  • CS professors rarely use real databases for their courses, and if they do, they use MySQL or MSSQL Server (if an educational institution has a license)
  • As a result, students do not have exposure to the real-world databases, performance problems, etc.
  • Also, new database research often does not reach Postgres hackers, and they might be unaware of new algorithms that could benefit them
  • At the same time, database researchers rarely use Postgres for their experiments

• Discussion:

Many computer science programs still focus on non‑PostgreSQL databases or skirt SQL entirely, leaving graduates under‑prepared for real‑world relational workloads. Participants noted that:

• • Students typically learn MySQL, never encountering PostgreSQL’s full, unrestricted feature set.
  • A trend toward NoSQL has further de‑emphasized teaching core relational concepts, causing confusion when students must scale beyond toy examples.
  • Curriculum decisions are driven by faculty and government standards, making it hard for instructors to introduce new technologies.

• Key Recommendations
  • Student‑Led Outreach: Organize informal, student‑focused events where peers can explore PostgreSQL hands‑on and network with industry practitioners outside of formal coursework
  • Sponsor Postgraduate Projects: Fund and promote advanced research or capstone projects that leverage PostgreSQL’s unique features, demonstrating its real‑world relevance in academia and industry.
  • Academic Partnerships: Engage professors via workshops and conference invitations, highlighting PostgreSQL’s ties to math concepts and its zero‑license-fee advantage.
  • Expand Outreach to Emerging Regions: Target regions where database curricula are still evolving (e.g., Africa, South America) by supporting inaugural local Postgres events and offering easy‐install packages.
  • Certification & Projects: Sponsor postgraduate research using PostgreSQL and explore official certification paths to give students concrete credentials.
  • Empower Student‑Led Awareness Campaigns: Provide incentives and resources for students to publish blog posts, tutorials, or case studies—peer advocacy can drive demand for PostgreSQL in formal programs.
  • Simplify Installation with User‑Friendly Packages: Distribute easy‑install PostgreSQL bundles (via yum, apt, or graphical installers) to lower technical barriers for students unfamiliar with system configuration.

By combining bottom‑up (student meetups, projects) and top‑down (faculty engagement, curriculum advocacy) efforts the PostgreSQL community can close the SQL knowledge gap and elevate Postgres into the top three databases taught in academia.

Improving processes or infrastructure/resources

Attending:

• Andreas Scherbaum, Jack Ng, Darsham Singh, Dave Page, Matthieu Doell, Magnus Hagander, Mark Waterbury, Peter Eisentraut, Claire Giordano, Franck Boudehen, Jelte Fennema-Nio, Álvaro Herrera, Michael Paquier, Daniel Gustafsson, Bryan Doyle, Mark Wong

Comm channels

• The postgresql.org website and mailing lists are the official communication channel
• Other channels are unofficial, but as they become known, people grow expectations about they also being sort of official
  • Examples: Telegram channels, Slack, Discord, etc.
  • Problem: their history isn't saved anywhere. People need to extract important data themselves.
  • There's no agreement on which one should be made official, so none is.
  • ... but maybe we should pick *some* (more than one).
  • If we do, we need to nominate official moderators, a team of moderators (3 - 5?) for each channel.
    • How do people add another discussion type site? We need a policy.
• That means the PostgreSQL CoC applies to those venues.
  • The team of moderators can enforce the CoC.
• A pgweb-committer is needed to update the website with this info.
• What about conflicts between the platform's Terms of Service and Postgres' CoC?
  • Naturally, both apply. The Postgres CoC adds restrictions to the ones that the ToS impose.

Website

• How do users find those platforms, looking at our website?
  • We should add links to the website.
• We could collapse the website so that it's not as many pages, considering that we don't have that much content
• ... except the homepage, which is too crammed already and there's too much scrolling.
• A website redesign apparently is needed.
  • Add a footer with lots of links (for Ctrl+F search)!
  • Change the "New to Postgres?" box in the homepage to something better. Maybe an in-browser Postgres instance with WASM or something, for newcomers to run on the spot.
• Stacey Haysler wrote a "Contributor's Guide" to help people contribute, with not only code. It would be good to promote that page better in the website.
• Improve the search function: exclude search in documentation (make this a separate flag).
• One page for how to submit a patch.
• One page for how to get involved.

Mailing lists

• Maybe we can remove the users mailing lists. They don't seem to be used very much anymore.
  • Devs don't get the input anymore about pain points for users, because most users don't post there.
  • Some mailing lists can be made inactive:
    • pgsql-gui-dev
    • pgsql-interfaces

Bugtracker

Statement: there is a high overlap with the CommitFest tool.

• Do we need a bugtracker?
  • Sure. But we don't have agreement that we have the manpower to maintain it.

Sources of bug reports:

• website form, send to bugs mailing list (after moderation)
• directly to the bugs mailing list (after moderation)
• bugs appear in discussions on -hackers

Type of bugs:

• not a bug / false positive
• small bug: fixed immediately (currently not appearing on the bugs mailing list)
• larger bugs
• mail without enough details (lack of details)

Bugtracker ID:

• Track process of a bug
• Track entries in Commitfest app
• Automatically update/close the bugtracker id

Requirements:

• list all bugs fixed in a minor/major version
• needs to support multiple fixed versions
• possibly pick up from -hackers, then generate a bug number

Wishlist:

• Have tags in mails (as part of Commitfest feature), which update the Commitfest status

Proposed ideas:

• Extra section in Commitfest app
• Cross-link patches to bugs
• Automatically update status from tags in mails

Intermediate features:

• parse emails and update CF status based on tags (does not interrupt existing workflows)
• needs a standard what tags are allowed (see standard tags for git messages)

What ideas we can borrow from other communities?

• Contribution turnaround time in some other communities is much better.
• Part of that is the Github/Gitlab workflow where a submitted PR goes through CI and can be pushed with a single click
• This also shows the test results directly in the PR, feature discussions happen on -hackers, patch review in the PR

How can we make the wiki more welcoming to contributions? Having to request editor turns people away.

• Pipe dream. That seems completely impossible.