I think finer grained consistency models (as well as some other options) would be a step forward for RDBMS systems. However, that doesn't get over the fact that the relational model is not always the best fit for your data. This is especially true if your data is semi-structured. I work with the MongoDB/10gen team and we have a lot of users who enjoy working with the document model, and have seen drastic reductions in both amount of code and time-to-production from it.

Just a vocabulary/definitions nit: Data modelling (relational, document, data-structure, whatever) is an independent concern from consistency.

I may want ACID properties but over a document-structured store, for example, and there's nothing contradictory in such a desire...

In fact, as a continuation of my "mix and match" consistency pipe dream; I'd like to mix-and-match data models within the same system, too! Strongly typed w/ integrity constraints; bag-o-data; etc...

But you can do that. SET TRANSACTION ISOLATION LEVEL SERIALIZABLE (or REPEATABLE READ) in the sessions doing your financial transactions, and in the sessions doing your chat message set READ UNCOMMITTED (and AUTOCOMMIT ON if you fancy). Easy. This feature has been around at least since the 90s in Sybase and its descendants.

Sure, but you can't take advantage of that looseness to scale a collection across a crapton of cheap nodes, either.

(Which would be the main driving factor for abandoning ACID in the first place.)

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.

1: http://hstore.cs.brown.edu/ 2: http://voltdb.com/

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.

Well,

As far I can tell, it would be easier to add layers of indexes, data control, schema control, transactions and so-forth on top of something like Tokyo DB than it would be to take apart a SQL database.

Easier, yes. But would it be better?

Layering transactions atop a key-value store would be very difficult to do efficiently, for example.