Whatever your feelings on whether or not NoSQL is actually about SQL – Michael … against a distributed eventually-consistent column store!…

There’s no reason why a SELECT statement can’t be implemented against a distributed eventually-consistent column store!

Now, implementing INSERT and UPDATE in such an environment is trickier, mainly because of things like the eventual consistency, updates might not occur in the same order on all replicas, unique-key constraints violations may not be detected until later, etc. However, the *syntax* doesn’t have much to do with that; just the *semantics* of what the application expects. Indeed, MySQL replication is as eventually consistent as any new-fangled NoSQL database; but it still uses SQL.

Also, you can use SQL alongside other interfaces to the same data, and pick the right tool for the right part of each application.

What we have done at GenieDB, therefore, is to write our nice replicated key-value store with its native API, then write a MySQL storage engine that backs into it. The resulting update semantics are pretty close to normal local tables, and we document the differences. And so people can access the same tables through SQL (subject to the restriction of a fixed schema) or they can go through the native API (for lower latency, and the ability to have different fields in different records of the same table, etc).

Best of both worlds!

And, in fact, for a lot of situations for which persistance, at least long-term persistance, isn’t nedessary. (Which is where memcached comes in.)

I generally agree with your sentiments. On the one hand it’s useful to have an umbrella term that refers to a bunch of stuff that isn’t a relational database. OTOH, NoSQL is getting used to cover very dissimilar techs which I’ve seen cause confusion.