Many argue which is better: PostgreSQL or MySQL. A recent post by MySQL evangelist and community manager Frederic Descamps prompted some criticism of the amount of time that it took for a particular bug to be fixed -- 14.5 years to be exact, from the initial report.

There’s a long list of technical and performance comparisons, but here’s the number one reason to choose Postgres over MySQL.

Community Drives Change

The PostgreSQL community is different than MySQL. First, MySQL is not a project; it is a product. Yes, they are both Open Source but Postgres is vendor neutral, contributor centric, and not controlled by any single entity. Using a product or project defines the culture you are embracing when you choose to use a particular software. For example, with Postgres you have true contribution capability to a project; with MySQL you support the profits of a single commercial entity (and Oracle's Larry Ellison owns his very own private island).

When you want education, professional development, and live community interaction about Postgres do you want to support a vendor neutral, community, and volunteer organized non-profit conferences or do you want to succumb to a brand? Postgres is a feature rich, ACID compliant, extensible database that offers best in class Relational, Document/JSON and High Availability support. It also has a license that allows you to build any product or project you want without hinderance. That’s why Command Prompt  uses, supports, contributes to, and recommends Postgres.

Let’s talk honestly about PostgreSQL for a moment. This might sting a bit, but our siloed arrogance doesn't help our community. It hurts it. Here are four things I hate about PostgreSQL and the PostgreSQL community:

Not a single decent community driven graphical admin tool

PGAdminIV and OmniDB are okay and getting better, but they are nowhere near as performant and professional as some competing products (Navicat, PostgreSQL EMS manager).

The lack of native partitioning until version 10

Yes, Postgres is a community driven effort and therefore the patches received are the ones the community can consider for inclusion. This is where working with a vendor such as MySQL is better than Postgres. If enough users demand it, MySQL must implement it or they lose customers. When you work with a community it isn't like that. We rely on the will and resources of others.

Lack of Vision

This is a frustrating one. Postgres has had logical replication for a decade but it was a bolt on (or a fork depending on version). It didn't matter how many people told the Postgres hackers that it needed to be in core. The hackers didn't want logical replication so it didn't happen. A decade later, we have logical replication largely via the resources and efforts of the 2ndQuadrant. A welcome change but it would be nice if it wasn't always such a battle to prove what is already proven (consider how long other competitors have had the feature).

The community silo

This issue is a big one. There are many in the Postgres community that are of the narrow-minded belief  that "The Community" is on mailing lists and on IRC. It is a dangerously restrictive view when we have many communities that all but don't participate within the "community channels." Russia, Japan, India, and Brazil are notable ones. Before anyone starts saying, “Well this person does…” yes, there are some participants from these regions, but they are far outweighed by the larger community. The Slack and Telegram channels are both larger than IRC, with almost 1400 members in each of those channels. The idea of the "central portal to community" died a decade ago and has only gotten more disparate. We as the PostgreSQL.Org community only hurt ourselves by continuing to ignore the wider and more inclusive vision.

The important part: What are we going to do about it?

I can go on and on about this as I live in a hybrid world of users and developers. I see both sides. I hear both sides. It is very important to be cognisant of the message we are sending. I have conversations with people every week that want to participate and help grow the community but aren't willing to for reasons related to the community culture:

• The next generation doesn't use email lists.
• The next generation doesn't bottom post.
• The next generation doesn't use plain text.
• The next generation doesn't use bare metal.

The next generation doesn't want you to tell them why their solution is wrong. They want you to answer the question they asked.

Do we want to continue to grow this community and have influence on the next generation to do it right? Or do we want to alienate them through old patterns, “get off my lawn” attitudes, and an inability to do great things because we are tied up in our own ideology? How do we as a community want to lead? I would like to to think that we would proactively, productively, and positively lead and thereby truly support and grow our community. That is how our Postgres community can be be different than MySQL.

The choice is yours.