kaamos

It is, in fact sensible without Enterprise Edition. The only thing it says is that page-level encryption in Community Edition is not intended as a regulatory compliance solution. Nothing more, nothing less.

Even in case you care about regulatory compliance, there are other options besides Enterprise Edition.

Does that comment say I'm listing features only available in MySQL Enterprise Edition?

Let me just tell you that I've read both links before.

No, this is all from MySQL Community Edition.

Without O_DIRECT, the page may be updated multiple times in the page cache before it hits the disk. The only thing PostgreSQL can do is to update the checksum before expelling the page from its own cache, so it will be doing unnecessary work in write-intensive workloads. But yes, hint bits and WAL is also a good point.

True, but then you can sing a similar song about PostgreSQL being the kind of guy that is cool all around, and is always there for that high school sweetheart, but still that badass MySQL gets all the fun and is always center of the party, which is oh so wrong.

OK, I see it now, thanks. I would even edit my original comment if I could. Still, the original article is biased without mentioning strict mode, the fact that it's been recommended to turn it on in any serious deployment for years, and that it is enabled by default in the latest MySQL/MariaDB releases.

There are reasons to choose PostgreSQL over MySQL (and vice versa), but the article is certainly an example of unfair evangelism.

It's just something I care about. You may call me an evangelist if you like, I consider myself an anti-evangelist.

Data integrity is of course important, and MySQL indeed has a weak story here, especially in older versions.

Is PostgreSQL flawless when it comes to data integrity? No, that would also be false advertising. Some examples:

- data checksums are disabled by default (silent data corruptions!), and the user manual specifically warns they are not cheap. And the reasons they are expensive is that PostgreSQL does not support O_DIRECT IO;

- removing a file on the filesystem may lead to a silent loss of data in PostgreSQL: https://www.postgresql.org/message-id/c571dfc5-91b0-0df2-4e3...

- some important control structures (which also impact data visibility and thus, integrity) are not even protected by checksums: https://www.postgresql.org/message-id/CAA4eK1L%3DXS3k7X9pfYK...

- there are no tools to verify replication integrity, similar to pt-table-checksum for MySQL; that would require statement-based replication, which is not supported in PostgreSQL, even in the next major release

> Nearly everything else in Postgres is set-it-and-forget-it.

There are many people who would disagree with that. Talking to Uber engineers would probably be a good idea to dispel that myth.

I know what I'm talking about. Over the last couple of years I had to speak to many people in the PostgreSQL community. While there are indeed many smart and nice people with balanced views and opinions there, the majority has this ideological bias. With ideology being that PostgreSQL is superior to MySQL in every single way. All counter-examples and arguments are usually ignored. I think it's something unique to PostgreSQL community, I've never met anything like that in other technical communities.

Agree, I might have misread the discussion. However, strict mode is on my default since MySQL 5.7 (released in 2015) and MariaDB 10.2 (which is also the version he was using). So he changed that, but didn't explicitly state it. Even when multiple people mentioned sql_mode.

The guy has deliberately changed a default setting (sql_mode) to make MariaDB/MySQL look worse. When someone pointed that out in the comments, he left it unresponded. Which is already telling something about PostgreSQL evangelism.

Speaking of comparing MySQL and PostgreSQL functionality, I've been spending some time recently on this very topic. Both are great databases with interesting and sometimes unique features. Here are some of the features PostgreSQL is missing as compared to MySQL:

- synchronous multi-master cluster (Galera, Group Replication)

- distributed in-memory grid with automatic sharding (NDB)

- semi-synchronous replication (will be available in PostgreSQL 10)

- built-in logical replication (will be available in PostgreSQL 10)

- built-in event scheduler

- clustered indexes

- declarative partitioning (limited functionality will be available in PostgreSQL 10)

- optimizer hints

- optimizer tracing

- efficient MVCC implementation that is unaffected by XID wraparound problems and VACUUM issues (see also Uber's report on moving from PostgreSQL to MySQL)

- page-level compression

- page-level encryption

- page-level incremental backups

- user variables

- NoSQL client APIs (HandlerSocket, memcached protocol, X protocol)

- virtual columns

- ability to choose data page size on database creation

- ability to specify column order when adding a new column with ALTER TABLE

- write-optimized storage engines similar to MyRocks and TokuDB

All of that may seem small from a developer's standpoint. Those things, however, are huge for people who design and operate the busiest websites on the internet. Which is probably why MySQL still shines in that field.

Oh yes, we should: https://bugs.mysql.com/bug.php?id=76927