0) Sergei and Justin - I prefer to avoid the "Monty says" game either for or against. We are trying to establish a community here. He is one of many. His reputation (good or bad) shouldn't be a stick that is deployed to win arguments.
1) RocksDB has persistent snapshots. That would make flashback trivial to implement for MyRocks assuming you took snapshots ahead of time. So maybe that isn't flashing back.
http://rocksdb.org/blog/2015/11/10/use-checkpoints-for-efficient-snapshots.html2) I expect almost everyone to choose MyRocks given a choice between MyRocks and TokuDB. I have evaluated TokuDB over several years. I have many performance and efficiency results from this year that I have yet to publish. Results are almost always much better with MyRocks, we have more resources dedicated to MyRocks so it will improve quickly.
MariaDB is a community project, so if someone maintains TokuDB I assume it will be included in MariaDB. But I think time is better spent on MyRocks. Our docs need to be updated and our communication needs to be better. But we move fast and Yoshi has been updating the limitations wiki page as I write this (
https://github.com/facebook/mysql-5.6/wiki/MyRocks-limitations).
I am not surprised that there are so few performance results published for TokuDB. And when they are published they are almost always for trivial workloads -- like insert-only insert benchmark. Try adding queries concurrent with the inserts.
3) Partitioning via the partition storage engine is supported for MyRocks. My employer doesn't need it for the initial deployment. It might be needed elsewhere and I am sure the community needs it. I assume we also need native partitioning in MyRocks when we move up to MySQL 8. The limitations page is getting updated to explain this.
4) By default the FB MySQL branch doesn't allow mysqld to start if MyRocks and InnoDB are enabled. This was misinterpreted to mean it wasn't possible to use MyRocks and InnoDB at the same time. It is possible now. And MariaDB/Percona are free to always allow both to be enabled. It was previously prevented in the FB MySQL repo because of fear that internal users might try to do a transaction that spans engines. I think that is a bad idea and XA scares me. I assume evaluations for MariaDB Server and Percona Server require that both InnoDB and MyRocks are enabled concurrently. See
https://github.com/facebook/mysql-5.6/issues/1065) We have work in progress to support XA for MyRocks. Code has been merged. Perf tests are in progress.
6) We have work in progress to support online DDL.
7) MyRocks supports read-committed (RC) and repeatable-read (RR). RR in MyRocks is Postgres-style and I assume that it won't get much use, just like i assume it doesn't in Postgres. If we add gap-locking to MyRocks RR then it will match InnoDB. For details see
https://github.com/mdcallag/mytools/wiki/Cursor-Isolation8) I am a long time user of SBR and think that RBR is the future. MyRocks needs RBR because we expect most deployments to use it with read-committed and just like InnoDB, that needs RBR. If gap locking is added to MyRocks RR then SBR is feasible, but you give up all of the great new replication features that will be RBR only.
http://dba.stackexchange.com/questions/101122/mysql-why-statement-based-binlog-format-cannot-work-with-innodb-read-uncommitte9) MyRocks could do transportable column family for all indexes/tables in a column family. Transportable is a nice feature but I don't think the lack of it is a big deal. It is part of being storage efficient, but the overall storage efficiency story is much stronger for MyRocks than InnoDB.
10) I hope there is a plan for foreign key and spatial in MyRocks. There isn't one yet. I don't think full text in any MySQL engine is a good use of time given how infrequently it is used.