That's not really a meaningful statement to make. A singular "better" seldom exists outside children's discussions. MySQL for a long time had a more compelling multi-master situation, for example, and was simpler to operate as there was no need to schedule vacuums and fewer reasons to stop the database during normal operation.

But none of that is really relevant for choosing a database. It's an enabler technology, just like an operating system. You seldom set out to use a certain database, you set out to use a certain application and then choose a database and an operating system that fits the application's use case.

None of that is true for containerization technology. Any requirements come instead from the infrastructure layer, and the application is made to fit those instead of the other way around. Other than that, you are free to choose whatever has the least complex operational requirements. If I was an investor in Docker Inc. I'd carefully consider what that means.

Now, implementing DBMS with even basic SQL query language, is not a trivial job.

Reception still doesn't seem great.

In past year, PostgreSQL not only caught up but also surpassed MySQL in terms of performance (I think MySQL might still be faster if you mostly read the data, but I'm not sure) and operational features, so at this point not only you have as fast (and actually faster for writing workload) but also have more features and much much better reliability. So it is no brainier to use it right now, but earlier you had to choose what was more important to you.

For many years MySQL had a much clearer multi-master replication story than PostgresQL. For most use cases, other features are secondary to replication.

I'd say the opposite - for most use cases, replication doesn't even figure into it. I guess we both need to find more solid evidence than our own opinions.

To each their own.

And there are a lot of systems for which downtime really is acceptable, at least for the amount of time it takes to restore a backup. Not everything is a front-end, mission critical system. I manage plenty of systems that are only used in a back-end batch context.

So I think it's crazy to suggest that how well a db engine's replication work outweighs all other factors. Depending on your situation it may well be the most important thing, but there's a lot of room for others to have well-architected systems that have different priorities.

The database is the hardest component to switch and even if the company were to disappear today, it would take decades to migrate off.

Docker has none of this. It only happened a few years ago, it will be gone as quickly. It doesn't even have a strong brand name, people want kubernetes not docker, docker is merely a dependency that can be replaced.

MySQL also had (relatively) straightforward replication features since way back, something that is much newer to Postgres.

For info, I used MySQL for over a decade, and am a relatively recent convert to Postgres - and I love it!