Today, in a distributed cloud environment, there is no good DB that can have both ACID and SQL support, at the same time keep the performance up. Though in some case it is true, it can’t be applied to all DBMSes. Berkeley DB, a famous Key/value based nosql DB, support most SQL statement as well as XML/XQuery, it also support Java object API.
noSQL means not only SQL, not means NO SQL. Mongo and its followers have set up a bad example for followers. a noSQL DBMS should not use SQL as it’s base query language, but it should can support SQL as a higher layer query language, just like what foundationDB tried to do. Of course, the problem is ACID, which is a rather difficult problem for a sharding DB,who becomes more and more common as the cloud computing is conquering the server world. SQL language itself is not difficult to carry out, ACID is.
But ACID is a must-have feature in many apps, not only bankers needs ACID, all app developer who want to make a simple but strong app must have transitions as one of their tools. No one can stand an app that only act normally when user got the luck. Those who want to throw away ACID can’t walk long as this is not possible for many things.
There are many ways to overcome ACID implement problem. In cloud, locking is an unacceptable way, unless there is some way to lock at a very small, accurate scale, which is not a easy job for 100+ sharding servers. Log and check is another way, which is easier than accurate locks, though it’s not an as easy and comfortable way as a single DBMS in an old good big lock, and will cause exe time limit in some implement. But it’s possible, and that’s enough.
If ACID is possible in a cloud environment, SQL will be, too. But it may exist as a layer top on ACID system based on some simpler API. Whatever, SQL will not be ended by noSQL and cloud, it will still be used in many places for whoever wants to keep data update easy(or even possible). Maybe one day there will be only copy and not reference in DB world, but I think the day has not come yet.