What is your performance and/or scaling issue and what alternatives are you considering?
In this particular case the scaling needs and performance issues made TokuDB an economical decision. As the researcher noted in the piece: "With InnoDB [the default MySQL storage engine], going to larger servers, adding 100s of GBs of additional RAM along with many additional drives would have easily cost $20,000 or more, and still would not have addressed all our needs. TokuDB was by far both a cheaper and simpler solution.”
To expand the MVCC list noted above, MySQL + TokuDB is always in MVCC as well (since version 5.0 last year). Also note that the Quora link describes Fractional Cascading. TokuDB uses Fractal Tree indexes. To learn more about Fractal Tree indexes as opposed to basic LSM, see here - http://www.tokutek.com/2011/09/write-optimization-myths-comp...
Good insight. As to your point -- keeping up many indexes with MyISAM or InnoDB is definitely a problem, especially if the indexes grow too big for RAM. In these cases, TokuDB (http://en.wikipedia.org/wiki/TokuDB), a drop in storage engine replacement for MySQL, can help by replacing dated B-tree technology with more modern Fractal Tree indexes, since B-trees suffer in performance with high insertion rates (especially random insertions) into disk. By allowing for faster write performance, Fractal Tree engines allow for more indexes to be maintained, and hence better query performance can be obtained.
Thanks for all the interest and for your patience...
-Tokutek