Why sell the idea of contributing to PostgreSQL to your employer

How contribution decisions shape the sustainability of the PostgreSQL ecosystem

Last week at PGConf.DE, I gave a talk titled Not Just Altruism: Selling PostgreSQL Contributions to Your Employer.

It didn’t attract a large audience. To be fair, it was right after lunch on the last day of the conference, and there was strong competition from two excellent technical talks. Plus… why bother talking to your employer about contributing to PostgreSQL? :)

The news this week that David Steele, the core maintainer of pgBackRest, one of the most popular backup tools in Postgres ecosystem, is stepping down, highlights a critical point: without ongoing support of contributors from companies in the PostgreSQL ecosystem, and community stewardship of PostgreSQL tooling, the sustainability of both the tools and PostgreSQL itself is at risk.

So what was my talk about?

In short, it was about the motivations, passion, individual sacrifice, and courage of current contributors; the lack of understanding many companies have when it comes to contributing to PostgreSQL (yes, those same companies that rely on PostgreSQL and its ecosystem for their products, services, and revenue); and the minuscule number of contributors compared to PostgreSQL’s ever-growing user base.

A few stats

PostgreSQL has repeatedly been named “DBMS of the Year” by DB-Engines. According to the Stack Overflow survey of nearly 500,000 developers, more than 58% of professional developers have done extensive development work in PostgreSQL over the past year.

So how many people actually contribute to PostgreSQL?

Here’s a rough calculation:

Additionally, there are many individuals who self-report their contributions e.g. those who contribute occasionally or in the short term, volunteer at events, organise meet-ups, review code, members of various Postgres committees and entities, speak about Postgres at non-PG conferences etc. They perform valuable work but are not yet formally recognised.

In the State of PostgreSQL survey by Tiger Data, 289 people self-reported as contributors (some of them may already be included in the 1,806, but let’s be generous and add them to 1,806).

That still amounts to only around 2,000 people contributing to PostgreSQL.

Could we have more?

Considering that there are approximately 30 million developers worldwide (an estimate by Evans Data Corporation), and that 58% of professional developers use PostgreSQL in their work (based on the Stack overflow developer survey), that’s roughly 17.4 million people relying on software developed and maintained by just 2,000 contributors.

So yes — we definitely could have more.

Why do people and companies choose to contribute to PostgreSQL?

You may think that those people and the companies supporting them must be very special to be willing to contribute.

To answer this question and to guide my presentation, I interviewed 15 individuals from the PostgreSQL community across 11 companies, representing roles from engineering leadership and DBAs to HR, executives, and sales and marketing.

It turns out they all benefit from contributing.

Individuals who contribute benefit from recognition by peers and management. They gain personal satisfaction from solving problems, fuelling their curiosity, and becoming more technically skilled — helping them stay ahead.

Socially, it allows them to join a global network of like-minded open source enthusiasts. They find meaning in community work — contributing to something larger than themselves and helping those without resources gain access to solutions like PostgreSQL.

As Joe Conway put it, it helps them find their ikigai — “a reason to wake up in the morning”.

It also enables collaboration across companies, allowing individuals to work alongside peers, and fosters the growth of new ideas, stronger partnerships, and greater diversity among those driving the project.

Companies that support contributors, in turn, see benefits across the entire organisation — from technical teams to HR, marketing, sales, product, and customer service.

• From a leadership perspective, it helps companies plan ahead and gain early visibility into what’s coming next — new features, changes, and direction. That insight feeds directly into better strategic decision-making.
• For technology teams, it’s about depth of expertise. Engineers who contribute understand how PostgreSQL works at a much deeper level. This translates into better architecture, faster problem-solving, and more reliable systems.
• In sales and marketing, contribution is a clear differentiator that builds credibility and trust. It creates a strong narrative: we don’t just use PostgreSQL — we help shape it.
• From an HR perspective, supporting contributions is a powerful tool for attracting and retaining engineers who want to contribute and be recognised by the community. It also enables them to develop new skills by collaborating with engineers from other companies — just look at the interactions on the hackers mailing list.

More broadly, it strengthens a company’s position in the ecosystem.

Your employees become recognised experts, your company becomes a known name, and you build relationships and trust that simply can’t be bought.

So why do we still have pgBackRest-like situations?

There are many factors influencing companies’ decisions to support individual contributors, as well as contributors’ decisions to continue working on a project.

I talked about it in my talk, and following David Steele’s announcement, several blog posts have addressed it as well (I’d recommend reading Christophe Pettus and Lætitia Avrot posts).

When we spoke, Bruce Momjian said: “companies will contribute to Postgres when it makes economic sense to them, and it doesn’t help to complain to them if they don’t yet see economic benefit. It takes 3–4 years for a company to see what they are missing by not participating in the Postgres community, so (they) just (need to) be patient because most companies eventually realise the benefits.” Which makes it, indeed, a difficult business decision.

As for community, it may need to be more mindful of the sustainability of tooling beyond the core PostgreSQL code. (If you are in Vancouver at PGConf.dev this May, join the session “To extend, to contribute, or to petition to core?” on 19 May, where this topic will be discussed.)

At the same time, “the community” includes not only companies whose employees are already actively involved, but also those that could take a more active role yet do not see it as their responsibility.

One thing is clear: PostgreSQL has given rise to an ecosystem of companies that feed on its open code to power their products and services. For this ecosystem to remain healthy, those who depend on it must be mindful of their source — and make deliberate business decisions not about whether, but how to sustain the PostgreSQL community and its contributors.

Whether a company building its business on PostgreSQL chooses to contribute back to the community is a conscious decision. If it does not see value in doing so, it should also understand that it is accepting the risk that key components may become less stable or sustainable as individual contributor priorities shift or interests and support from other companies changes.

…and yes, choosing not to contribute is still a decision.