1) I did hedge by saying "most serious load patterns". Yes, if you're
doing inserts and selects only, MyISAM is fine. As soon as you have a
significant number of deletes or updates, its performance drops like a rock
due to lock contention -- any pending update or delete will block *all*
queries until a) all currently executing select queries have finished (so
the update or delete can begin), and then b) the update or delete finishes.
MyISAM has other critical flaws. For instance, if mysqld crashes, or even
sometimes if queries get killed, tables can become corrupted. This
requires a repair, which can take multiple hours on a large dataset.
Replication is (usually) statement-based in MySQL, so as far as I know,
it's always worked for any storage engine. It's certainly worked on InnoDB
since at least 4.0 (released in 2003), and I know that for a fact because
Wikipedia used 4.0, InnoDB, and replication until very recently.
MyISAM has a few advantages over InnoDB. For instance, it supports
fulltext search -- but for real work you don't want to use it, you want to
use an external search provider like Sphinx or Lucene, since those perform
vastly better. It takes up less disk space, but that's usually only an
issue with stingy shared hosts that limit your database size; disk space is
cheap. There are a few other goodies like prefix compression of indexes
that InnoDB doesn't have yet.
It makes sense to use MyISAM in some limited circumstances. But without
InnoDB, MySQL *would* be crippled, and it *would* make more sense for
InnoDB to be the default storage engine so MyISAM is relegated to the niche
use cases it's good at. So my point holds.
2) Falcon is dead, isn't it? The creator of Falcon, Jim Starkey, quit
MySQL in June 2008. It was meant to be the hallmark feature of 6.0, but
now the MySQL website officially says 6.0 is no longer being worked on.
Resources have shifted to Maria and InnoDB.
In any event, it seems premature to compare Falcon and InnoDB when InnoDB
has been in production use for a decade or so, while Falcon never
progressed beyond alpha. You can't call alphas "substantially better" than
shipping software; they aren't even usable.
3) Sure -- but they haven't killed InnoDB, and could have done so at any
time to MySQL's massive detriment. It's unlikely they'll try to kill
MySQL. It's possible, but then it will just be forked, or pgsql will take
over, or whatever. I don't think it's much to worry about.
4) Yeah, ZFS still has lingering reliability problems. But it's still
several years ahead of btrfs. Even if it's not quite ready for some sites,
it will be ready a lot sooner than any comparable alternative (and btrfs is
the only one of those).