You nailed it. The downside of NoSQL is that you have to deal with some proprietary API. SQL and tables can be quite useful for development purposes on some apps.
So check out H-Store[1], now commercialized as VoltDB[2]. You get full ACID, while staying with SQL, but also extremely fast performance and near-linear scaleout.
In my own tests (on call completion, save record and debit customer balance), I was easily to push over 100,000 transactions/sec on a 3-server cluster (low end, sub-$1000 servers). This is while maintaining full ACID and using SQL.
It's an interesting approach, though let's be careful about how we define scaling -- with "full ACID" there are always operations that will make the system go pear-shaped, no matter how cleverly designed the system is.
Personally: I like transactions, but I'm not in love with SQL; additionally I'd like to have the options of:
- deploying systems, or portions of a system, that continue working when widely distributed over cheap, unreliable networks and running on cheap, unreliable hardware.
- Support large datasets (more slowly) but pay $100/terabyte instead of $LOTS/terabyte.
Of course, everything has its downsides -- which is why my stated desire for a do-everything DB is a bit of a pipe dream.
So check out H-Store[1], now commercialized as VoltDB[2]. You get full ACID, while staying with SQL, but also extremely fast performance and near-linear scaleout.
In my own tests (on call completion, save record and debit customer balance), I was easily to push over 100,000 transactions/sec on a 3-server cluster (low end, sub-$1000 servers). This is while maintaining full ACID and using SQL.
1: http://hstore.cs.brown.edu/ 2: http://voltdb.com/