The problem is MySQL etc doesn’t are not designed for this so while they become a lot faster they are still relatively slow. Also, RAM is only getting larger so once you make the transition to a RAM based DB you are unlikely to need to transition back. PS: I suspect most real world workloads revolve around small datasets that connect to big blobs of data. Think Users/Projects linking to Pictures, Documents, and Video etc. You don't edit documents in your database but you do want to track version information, users, permissions timestamps, approval etc. It's often a good idea to mix a Key Value style data store with a front end SQL database.
* A system which holds all data in memory is faster than a system which uses memory and disks. True, but not really news.
* If you leave out features your implementation can be faster (e.g. they only support transactions which span a single stored procedure). Again .. no news here.
Something else I've missed?
* Leaving out features is harder than adding features, because you have to judiciously decide which ones to leave out. A large bushel o' features can have many different subsets, and only some of these subsets are worthwhile.
That said, VoltDB's architecture was built for in-memory and horizontal scaling from day 1. Based on hstore (http://hstore.cs.brown.edu/), it's not simply a removal of what's in existing systems.
Thus the question would be, does the performance advantage of VoltDB's approach outweigh the penalty of static RAM performance?
I think the last thing I used that would qualify as such was the Apple Newton.