Well, if I was advising you - like I do for many startups and companies - I would ask the same question that Henry asked - what are your requirements? MMORPG - is not a requirement.
What is a requirement is and what is needed is defining:
1) Size of object being stored
2) MOST IMPORTANT - I STRESS this MORE than TPS - contention requirements. Are you allowing players to act and interact within the same space? Will they be messing with each other's lives? If yes - this removes a a fair number of options, including MongoDB - whose real ONLY strength is in single player non contention gaming scenarios.
3) Yes - TPS
4) Read rate - versus write rate. This is important because if all u are doing is writing and little reading - think log files, sure Cassandra is the winner. What if you are reading and writing - think session caches and the sort, where every real action involves a read and write, in those cases Cassandra is not very good at all, and things like Riak and Couchbase crush it.
5) Next and very important is besides the read/write rating - how slow is one versus the other? I state this because if the writes are high but they are not needed in realtime, while the reads are - and old cache values are ok, then the architecture - can vary significantly. However, if the read rate and write rate and their performances vary greatly, and worse - they need to happen in RT and they are of equal importance - then this will require a larger set of technologies to make it work
Finally, there is always the WHO CARES approach. This approach is the true and tried approach for almost every startup I know of. It works great as long as you do TWO things:
1) You create a clean and layered abstraction for the code - so that as you change out back ends - tour system does not get affected.
2) You promise it will happen :-) Though if you are succeeding - you will be forced to do so.
