Like [programming] languages, there are pros, cons, and trade-offs for each flavor.
There are stores that are ahead in providing better, "runtime" control over facets of the CAP theorem -- ex. Cassandra.
There are stores that have several and more expressive datatypes -- ex. Redis.
Then there are stores like InnoDB, which some are more familiar with its pairing with MySQL. The interesting parts here, as far as one store to rule them all, are developments like HandlerSocket or building other structures atop the same store -- ex. Voldemort.
Similarly, there are stores that share a common filesystem [structure] and can be queried in different manners -- ex. Apache HBase (or any Hadoop / HDFS based system).
I wish the blog post went into more details about which Netflix services are implemented with SimpleDB, HBase, and Cassandra. He stresses that these (seemingly very similar) systems have unique capabilities, but he doesn't explain why they need all of them.
But these are all, like you said, stores. The RDBMS-equivalent term is "database engine"; one database management system can have multiple engines (like MySQL's InnoDB and MyISAM, for example) while keeping all its query parsing, planning, optimization, networking, etc. in common.
There are stores that are ahead in providing better, "runtime" control over facets of the CAP theorem -- ex. Cassandra.
There are stores that have several and more expressive datatypes -- ex. Redis.
Then there are stores like InnoDB, which some are more familiar with its pairing with MySQL. The interesting parts here, as far as one store to rule them all, are developments like HandlerSocket or building other structures atop the same store -- ex. Voldemort.
Similarly, there are stores that share a common filesystem [structure] and can be queried in different manners -- ex. Apache HBase (or any Hadoop / HDFS based system).