MySQL 8.0 features which will improve a DBA's life | Hacker News Reader

MySQL 8.0 features which will improve a DBA's life

lefred.be

50 pointsokket10 comments

So, can anyone explain what's the state of MySQL vs. MariaDB in 2018 and going forward? It's hard to find up-to-date information on this. A few years ago, everyone simply assumed that Oracle would kill MySQL, which it seems they didn't, but it's unclear two me what kind of sustained development one can expect from either of them.

They are both under heavy development. MySQL is still increasing revenue for Oracle, and MariaDB raised another $27M towards the end of 2017. They're both here to stay. The less clear question in my mind is how long they will remain compatible.

There's no official release of MySQL 8.0 yet, correct? Or... something that isn't an RC?

I was confused by the numbering, but perhaps never paid attention to major point releases before. I saw 8.0.0, 8.0.1, etc through 8.0.6, but looking closer, they're all dev or RC releases, but nothing has been declared 'production ready' yet, officially (or so it seems). Will that be reserved for the 8.1 label? Or will we just see something like 8.0.11 as the first "production release"?

EDIT: thanks for the replies - GA is the term I need to be looking for.

EDIT 2: Also: https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html is a decent overview both of new features and removed/deprecated stuff.

You are correct - it is currently in RC. The GA release will be a named point release. For example, in 5.7 it was 5.7.9: https://dev.mysql.com/doc/relnotes/mysql/5.7/en/

After several months when they feel okay they will tell us that using MySQL 8 is safe. They did the same thing for 5.7 and 5.6.

There will be atomic DDLs, which is great. I didn't understand if this means that a DB migration altering multiple tables can be embedded in a transaction and rolled back in case of errors, like with PostgreSQL, or if it's only the single operation that became safer.

The short answer is that it is only single operations that become safer.

I don't want to undersell it though: some single operations require multiple steps (i.e. DROP SCHEMA in 5.7 needs to unravel all the tables it discovered and making sure a replica slave produces the same result. 8.0+ does this much cleaner). So it still remains important to have.

I'm currently in the process of trying to get the team at my new workplace to switch from MySQL to PostgreSQL. They chose it before I started and are now complaining about features it lacks (but Postgres has. Actually, some of the things they're complaining about can be done with MySQL, if only they knew how to use it, or knew enough to run a non-ancient version of it).

MySQL just seems like the amateurish "I don't know about databases but I need one" choice.

MySQL has several features Postgres doesn't have, and there's tradeoffs between them. As a bonus, choosing MySQL doesn't make you smugly dismiss everyone else's database choice, unlike some other databases.

> As a bonus, choosing MySQL doesn't make you smugly dismiss everyone else's database choice, unlike some other databases.

Maybe, but in my case I was smugly dismissive of others before I ever encountered Postgres.

Reply on news.ycombinator.com