MySQL 5.7.6 is out

How active is the MariaDB development compared to MySQL's?

Should we still be concerned with Oracle trying to kill MySQL? How has that whole debacle played out?

Regarding corruption, it's an anecdote, but my girlfriend has lost a ton of data for her thesis related to innodb corruption. It took me hours of bit-twiddling to get the data back (and into Postgres where it's safe and accessible since then - on the same hardware, so don't blame this to broken hardware)

Now I can totally accept that this might have been a one-time fluke, but I personally really have trouble trusting a DBMS once it has lost data due to causes other than user-error or hardware faults.

1. Indexes are too simplistic. You can't index the output of a function.

2. InnoDB lacks full text search. MyISAM has it, but MyISAM is bad since it doesn't support transactions.

3. Unicode support by default does not support all Unicode characters. That's right, even though it says UTF-8, not everything is supported, and you have to specifically enable support for some character subsets for your DB.

4. MySQL replication is... how should I put it? Delicate. There is no integrity checking, and since by default it's just replaying an SQL log you can easily get inconsistencies between the master and the slave. There are lots of ways to confuse replication, such as `INSERT INTO my_table (foo) VALUES (RAND())`. There are no built-in tools for integrity checking the slave, and the third party tools that exist have to resort to some really crazy things, like re-inserting tables. I could go on about replication, and its issues for a while, but I want to move on to the other points.

5. No transactional DDL. This really sucks when using with something like Django migrations.

6. No point in time backups. You either use mysqldump with a transaction (you aren't using MyISAM, right?), or you stop the database server.

7. Logs suck. No, really, have you tried debugging an issue with your queries, deadlocks, configuration errors, etc.? MySQL's server logs (not query logs), are not very verbose, and what the do write is mostly useless.

8. Row level locking semantics are at times doing unexpected things. Last time I used MySQL for complex real time write-heavy stuff, I actually moved to advisory locks instead (the support for which is not exactly great in MySQL and could be expanded). This invites contention, deadlocks, and other nastiness where it isn't necessary.

9. No IPv6 support.

10. Can't index Archive engine tables.

11. Can't partition tables by any arbitrary value. It has to be only specific types which makes it too restrictive.

12. GIS support is not really there. Lots of basic features aren't supported.

13. No materialized views. You can simulate it with triggers, but that's not nearly as convenient.

14. No async drivers.

Note that these are very specific features. If you don't use them, good for you. No reason to switch away from MySQL just because. It has some advantages over Postgres as well:

1. Simple user management.

2. Simple database management. No schemas, objects, etc., just tables and views here.

3. INSERT IGNORE and REPLACE! You don't need to create triggers for these.

4. Decent performance out of the box, and lots of knobs to turn when tuning.

5. Generally, doesn't require a ton of setup time. Install it, create user and DB and code away (Postgres and lots of others have this too, but it is a good feature).

6. Large amount of community brain share, so you won't be braving a new world here.

So, basically, go ahead and use it if it works, but I'd say Postgres deserves a try too and your 4 points apply to it equally as well.

2. InnoDB has fulltext from MySQL 5.6+

3. I agree utf8mb4 should be renamed "utf8". When this was introduced it was given a new name to support downgrades, but the feature does exist :)

4. RAND() is actually deterministic (via other meta data written to the binlog). In any case, MySQL also supports Row-based replication and it is the proposed default for 5.7.

5. I would like to have this feature too :) It is important to note that few databases have this though.

6. MyISAM is no longer the default. PITR works fine with InnoDB.

7. The logging verbosity can be changed. In MySQL 5.7 there is a new server logging API which makes sure the output format is consistent. For some of the meta data you are suggesting, the better place to retrieve this is performance_schema.

8. You are probably talking about gap locks etc. These are required for statement-based replication, with Row-based they are not required.

10. I would suggest that ARCHIVE engine is of limited use-cases.

11. Please see http://mysqlserverteam.com/the-mysql-5-7-6-milestone-release... (search "innodb native partitioning"). Allowing more arbitrary functions would most likely require global secondary indexes. 5.7.6 contains an important change to move in that direction.

12. GIS support is improved dramatically in 5.7, including InnoDB support. Please take another look :)

14. I agree on this one. Async drives is becoming very important :)

RE: Point #4 in your second list, MySQL 5.6 contains much better configuration out of the box: http://www.tocker.ca/2013/09/10/improving-mysqls-default-con...