Hidden changes indeed... I'm glad Oracle did a blog post about this, because otherwise it's largely missing from the MySQL documentation. This is really disappointing considering that 9.6 was released over two weeks ago, yet as of this moment:
As an independent software vendor providing solutions focused on MySQL, honestly I find this situation to be deeply concerning.
I have heard that an Oracle exec made a lot of promises about renewed MySQL Community Edition attention at a pre-FOSDEM event a few days ago; can we take any of that seriously if even basic documentation updates are not occurring?
Back in the day (MySQL 5.0-5.5 era, when I was working at MySQL/Sun/Oracle in the MySQL support team) the MySQL documentation team was truly amazing and sets the standard for me even today compared to many other docs teams I see.
They had a very long and comprehensive manual. The manual on each page inter-linked easily to switch between the relevant page for different major versions with a dropdown version selector (3.x, 4.x, 5.0, 5.1, 5.5..etc).. and if a page had moved or didn't exist it always accurately redirect to the correct page as you did that switch.
And almost every single engineering change that ever mattered to me made it into the changelog and also had relevant docs. I could largely rely on it and didn't need "git log" like I mostly need today to figure out what changed in a version.
Partly this was process, every closed bug/change went to the docs team to process.. but the team was also fantastic and converting that into relevant docs and writing great docs.
A shame if that has been lost, they did have a stack of layoffs recently in MySQL.. apparently the developer team is also heavily down from where it was. I am sure this writing is a little biased but interesting reading never the less:
https://mariadb.org/reading-the-room-what-europes-mysql-comm...
This is great news for me. Recently I have been trying to set up a simple
solution to replicate a MySQL database into DuckDB, without the whole CDC shebang (kafka, debezium etc.). The biggest problem I faced was the fact that
cascaded operations are not captured in the logs and so they would not make it into the replica. Every workaround I could come up with was slow and/or fragile. It sounds like these up-coming changes will simply make that problem disappear - hurrah!
InnoDB's use of a clustered index for PK (has pros/cons, but better for some workloads)
Ability to use alternative storage engines such as MyRocks (LSM based instead of B-tree; best-in-class compression)
Support for index hints (so query plans won't randomly change and bring your site down)
More mature logical replication (fully supports DDL, has no concept of limited "replication slots", etc)
That all said, there are also many areas where Postgres is better! Like all things in computer science, there are architectural trade-offs, and no single silver bullet is the best choice for all workloads.
Why act so snobbish about it? They're both cromulent databases. You should try doing one project with each. The converse of this list would tell the diehard postgres user that mariadb is irrelevant to him.
They have quite different internal design, this affects what features are possible. No clustered index in postgres for instance, and UPDATE can reorder rows, but it supports replication much better.
That's totally fine, there are many workloads where Postgres is the best choice! I'm not forcing you to use it, I was just responding to the comment upthread about lack of advantages. It's kind of bonkers that the anti-MySQL crowd is so rabid that any attempt to explain legitimate use-cases for MySQL is met with a barrage of downvotes, especially in a submission that is directly about MySQL specifically :/
Hidden changes indeed... I'm glad Oracle did a blog post about this, because otherwise it's largely missing from the MySQL documentation. This is really disappointing considering that 9.6 was released over two weeks ago, yet as of this moment:
* The new innodb_native_foreign_keys server variable has only two vague sentences describing its effect: https://dev.mysql.com/doc/refman/9.6/en/innodb-parameters.ht...
* The MySQL 9.6 release notes make no mention of foreign key changes whatsoever, nor of the innodb_native_foreign_keys variable: https://dev.mysql.com/doc/relnotes/mysql/9.6/en/news-9-6-0.h...
* The "What is New in MySQL 9.6" manual page is currently just a copy-and-paste of that page from MySQL 9.5, with all the "9.5"'s replaced with "9.6": https://dev.mysql.com/doc/refman/9.6/en/mysql-nutshell.html vs https://dev.mysql.com/doc/refman/9.5/en/mysql-nutshell.html
As an independent software vendor providing solutions focused on MySQL, honestly I find this situation to be deeply concerning.
I have heard that an Oracle exec made a lot of promises about renewed MySQL Community Edition attention at a pre-FOSDEM event a few days ago; can we take any of that seriously if even basic documentation updates are not occurring?
Back in the day (MySQL 5.0-5.5 era, when I was working at MySQL/Sun/Oracle in the MySQL support team) the MySQL documentation team was truly amazing and sets the standard for me even today compared to many other docs teams I see.
They had a very long and comprehensive manual. The manual on each page inter-linked easily to switch between the relevant page for different major versions with a dropdown version selector (3.x, 4.x, 5.0, 5.1, 5.5..etc).. and if a page had moved or didn't exist it always accurately redirect to the correct page as you did that switch.
And almost every single engineering change that ever mattered to me made it into the changelog and also had relevant docs. I could largely rely on it and didn't need "git log" like I mostly need today to figure out what changed in a version.
Partly this was process, every closed bug/change went to the docs team to process.. but the team was also fantastic and converting that into relevant docs and writing great docs.
A shame if that has been lost, they did have a stack of layoffs recently in MySQL.. apparently the developer team is also heavily down from where it was. I am sure this writing is a little biased but interesting reading never the less: https://mariadb.org/reading-the-room-what-europes-mysql-comm...
This is great news for me. Recently I have been trying to set up a simple solution to replicate a MySQL database into DuckDB, without the whole CDC shebang (kafka, debezium etc.). The biggest problem I faced was the fact that cascaded operations are not captured in the logs and so they would not make it into the replica. Every workaround I could come up with was slow and/or fragile. It sounds like these up-coming changes will simply make that problem disappear - hurrah!
yeah but it's Oracle. You want MariaDB now.
I prefer PostgreSQL. Don't see any advantage of MySQL/Maria.
A few major areas where MySQL/MariaDB excels:
Threaded connection model (no process spawning)
Undo-based MVCC (no need for vacuum)
InnoDB's use of a clustered index for PK (has pros/cons, but better for some workloads)
Ability to use alternative storage engines such as MyRocks (LSM based instead of B-tree; best-in-class compression)
Support for index hints (so query plans won't randomly change and bring your site down)
More mature logical replication (fully supports DDL, has no concept of limited "replication slots", etc)
That all said, there are also many areas where Postgres is better! Like all things in computer science, there are architectural trade-offs, and no single silver bullet is the best choice for all workloads.
Your list confirms that MySQL is irrelevant to me.
Why act so snobbish about it? They're both cromulent databases. You should try doing one project with each. The converse of this list would tell the diehard postgres user that mariadb is irrelevant to him.
They have quite different internal design, this affects what features are possible. No clustered index in postgres for instance, and UPDATE can reorder rows, but it supports replication much better.
That's totally fine, there are many workloads where Postgres is the best choice! I'm not forcing you to use it, I was just responding to the comment upthread about lack of advantages. It's kind of bonkers that the anti-MySQL crowd is so rabid that any attempt to explain legitimate use-cases for MySQL is met with a barrage of downvotes, especially in a submission that is directly about MySQL specifically :/
What do you see as advantages of postgres over mysql? I see these comments at work quite often and there isn't always much substance behind them
Different concurrency model
I think it's a good idea, as a decades long user of InnoDB. I hope that the work can be shared with other forks of MySQL
I mean great, but there are 0 commits in 2026 Github for MySQL. I think pretty much everyone is planning a transition to MariaDB or Postgres.
MySQL is a beloved OSS product and project. Losing influence over that would be a massive mistake by Oracle.
Citation: https://github.com/mysql/mysql-server/commits/trunk/
>It's because MySQL apparently does development in-house in a git repository and only occasionally pushes it to GitHub
https://optimizedbyotto.com/post/reasons-to-stop-using-mysql...
I saw that page, but interestingly enough I don't see that quote on there
https://www.percona.com/blog/separating-fud-and-reality-has-...
This has been debunked, they've never used Github as their main development area