Reasons to choose PostgreSQL 9.6

the consistency issues come from the handling of those filesystems by the control interface above it.

I'm fairly certain innodb by itself is pretty decent, in fact you can configure away the horrible behaviour nowadays, but I'm usually called in when things go wrong- and people usually keep the defaults.

For a very long time, MySQL had much, much better replication and some people would argue that it still does. It would be nice if MySQL were a little less lax in other regards, but replication is always going too be more important for production sites.

I'm a Postgres convert. I used MySQL back in the day because I'd heard of Postgres and everyone said tuning it was a nightmare. May or may not have been true but there's enough documentation and books now, and maybe the configuration has become simpler. I no longer hear that Postgres is hard to configure but that it's an OSS enterprise RDBMS that's continuely improving. Even better, I've experienced that improvement over the last few years.

> In my experience, most people who used MySQL simply hadn't heard of PostgreSQL

That just means the next question is, "why hadn't they heard of PostgreSQL"? It's not as if MySQL AB was taking out ads in the newspaper to create mindshare.

You'll get people who still pick C "for performance" when writing a system that has to handle about 10 requests/second. We have this strange desire to use "the fastest" regardless of whether performance actually matters for our use case and how much we're giving up for it.

nowhere near as intuitive as SHOW DATABASES.

Can you cite examples in recent versions? In my experience, the defaults in recent versions (mixed or row-based replication, strict sql mode) are quite sane and prevent most historic problems.

I don't have enough pg experience to make a valid comparison, but I have worked extensively on the largest mysql environment in the world (among many others), and can say that properly-configured mysql replication does not encounter the problems you are describing.

Yes, there are a lot of pitfalls for novice admins to avoid. That's true of all databases to some degree. MySQL may well have more pitfalls than others, but it also has a much wider net of experts who can help you avoid these pitfalls.

Anyway, by "mature" I was also referring to the sheer number of solutions offered, most of which are now battle-tested by many large users. Out-of-the-box in the latest version you get 2 types of logical replication (and a third type mixing the two), 3 options for level of synchronicity (async, semi-sync, and now sync via the new group replication), bidirectional replication, and multi-source replication. And there are additional third-party solutions for other synchronous replication setups (e.g. Galera), and even physical replication has been implemented internally by both Amazon and Alibaba.

Mature to me means having a wide feature set, and a history of successfully working at varying scale and workloads.

A lot of people like to bash MySQL, but without citing specific examples, or by referring to problems that haven't been true in a decade or more.

I've listed a large number of huge corporations that have had great success with MySQL, and have decided to stay on MySQL despite having the resources to migrate away if they saw a compelling reason. Some of the companies on that list are relatively new, yet still chose to start with MySQL, or migrate to MySQL after scaling.

If MySQL is as flawed as people in this thread insist, why are so many companies continuing to use it and even migrating to it? In a few cases I can provide a first-hand answer, and maturity and ecosystem are two of the biggest factors.

> we don't know if they use bare bone MySQL or not

No, we know this exactly, because companies freely discuss it. (I've worked for 2 of the companies I listed, and over the years have attended conference talks by pretty much all of the other ones I mentioned.)

The vast majority of these companies use an unmodified copy of either stock (oracle) MySQL, Percona Server, or MariaDB. Of these 3 major options, Percona Server is the most common among large-scale companies.

The companies that modify MySQL (Facebook, Twitter, LinkedIn, Google, Alibaba) readily open-source their changes. They're not really forks, it's more like a patch-set that they port to new versions. They make nice improvements that are often incorporated into Percona Server and some eventually are reimplemented by Oracle to be put back upstream.

The one big exception is Amazon, which doesn't open-source its changes. But aside from them, it's an open source ecosystem. Having companies with "expertise to modify MySQL and use their own branch" is a good thing and this is exactly why it's a good example of MySQL's popularity!

Compression is not really that useful except on large values or large numbers of values. Other than column stores, I don't think most storage engines actually compress the data (as opposed to indices) across rows (because it would slow down reads and writes dramatically) so there's really no point in compressing tiny strings. Page-level compression might be useful, I guess, depending on your use case.

That's more an orthogonal angle. Row stores (what you usually want for oltp workloads) usually achieves a lot lower compression ratios than column stores (more useful for write once analytics use cases). If you think about it, that's not too surprising. Columns in a row will usually have largely independent values (cf normalization), thus a sequence is rows is harder to compress; in column stores all the values for a column follow each other, and quite often that allows for far higher compression ratios.