Postgres: the next generation. Investing in the next generation of committers.

PostgreSQL isn’t getting any younger. Which is fine – after all, databases generally improve with age. The platform is going from strength, and is a default choice for a big chunk of modern software development. But Postgres has been around for a while – it launched in 1986 – which has an implication for the folks actually building the database. Just how long will they want to do the heavy lifting of maintaining a high profile codebase that so many folks rely on? Postgres is a close knit group and project. Robert Haas, Postgres committer and chief database scientist at EnterpriseDB writes a regular contribution post and the latest numbers are salutary – Who Contributed to PostgreSQL Development in 2022?

I calculate that, in 2022, there were 192 people who were the principal author of at least one PostgreSQL commit. 66% of the new lines of code were contributed by one of 14 people, and 90% of the new lines of code were contributed by one of 40 people.

The core development community is aging somewhat – the average age is probably around 50. Which is totally fine. 50 year olds are more than capable of doing a shitload of work – don’t ask me how I know. Tom Lane, who works at Crunchy Data, is 68 and he’s still the Postgres project’s fulcrum. Long may that continue.

The Postgres community is amazing. Open Postgres governance is something we can and do rely on, which is refreshing in the current era of commercial open source licensing rugpulls. But as an axis to consider in terms of open source sustainability let’s assume that Postgres is still going strong in say, 20 years. Who is going to be doing the work in 2043? I had a fascinating conversation with Nikita Shamgunov, CEO of Neon recently and one of the subjects we discussed was aging in tech projects and its relationship to project sustainability. Neon is a fully managed Postgres database optimised for serverless apps, separating storage from compute – the database is just a URL. That’s the design principle. It allows for branching, with preview deployments – thus Neon’s partnership with Vercel. Make it easy, make it modern, make it a zero config API. Neon has 62 employees and has raised $108m so far. It competes with the likes of Supabase. But back to the subject at hand.

According to Shamgunov:

If you look at the Postgres committer crowd they’re in their 50s, 60s, 40s and maybe a few in their 30s. It takes a lot of effort to become a committer but very little to be a contributor – you just need to write good code.

I think we’re doing good to the world by hiring more junior people and training them to become committers and hopefully maintainers. It’s very important that the Postgres engine continues to evolve.

Neon is being intentional about investing in the next generation of contributors, committers and maintainers. The natural move for a lot of companies is to try and hire the existing top talent, rather than fostering new blood.

We debated whether to just find more Postgres committers and hire them. But it’s not clear that would be spending our money in the best way. If we train new ones it’s better, and that’s how we can keep ramping the Postgres team.

There are some interesting questions here. For example – consider Neon’s IP, which is currently permissively licensed, but Shamgunov is not an open source zealot. What happens if in a few years the company decides to relicense, as other database companies have – see for example Redis, MongoDB and Elastic. Neon would be perfectly within its rights to relicense under more restrictive terms, potential community blowback aside. But any code they had contributed to Postgres? That’s not going to be affected. Having core Postgres maintainers on staff is a pretty good example of enlightened self interest and should serve to keep the company honest. Whatever decisions Neon makes in future, assuming they have employees dedicated to making Postgres better, then the community and core codebase still wins.

Cohort aging is certainly not a problem that’s unique to Postgres. Anyone remember the year 2000 bug? Communities and ecosystems do get older, which can be an issue when it comes to skills and staffing and rejuvenation. IBM has done a great job of bringing younger developers into the mainframe fold, for example with vocational education programs at universities – here is a post I wrote about that a while back.

There are plenty of projects with literally millions of users that are run by one or two people and don’t have the level of corporate sponsorship with see with projects such as Postgres or even Kubernetes. Postgres isn’t in any sense struggling to attract new users – there are plenty of 22 year olds defaulting to it today. It’s a hugely popular platform. But yes, ensuring the ongoing maintenance of the project will require some intentionality, funding, and enlightened self interest.

 

Disclosure: Neon is not a RedMonk client. Crunchy Data, IBM and Vercel are all RedMonk clients. This piece is published independently of any client relationships.

The illustration above was created with Midjourney.