NoSQL “movement” roadblocks HTML5 WebDB

Today’s rant is coming between me and a day of skiing so I’ll keep it brief. While trying to get to the bottom of why I can’t enjoy offline access to Google Apps & other web-based applications with Gears on Snow Leopard I came across a post noting Chrome, Opera to support html5 webdb, FF & IE won’t. This seemed curious as HTML5 is powering on towards last call and there are already multiple implementations of both applications and clients that run them. Here’s where we’re at:

  • Opera: “At opera, we implemented web db […] it’s likely we will [ship it] as people have built on it”
  • Google [Chrome]: “We’ve implemented WebDB … we’re about to ship it”
  • Microsoft [IE]: “We don’t think we’ll reasonably be able to ship an interoperable version of WebDB”
  • Mozilla [Firefox]: “We’ve talked to a lot of developers, the feedback we got is that we really don’t want SQL […] I don’t think mozilla plans to ship it.”

Of these, Microsoft’s argument (aside from being disproven by existing interoperable implementations) can be summarily dismissed because offline web applications are a direct competitor to desktop applications and therefore Windows itself. As if that’s not enough, they have their own horse in this race that they don’t have to share with anyone in the form of Silverlight. As such it’s completely understandable (however lame) for them to spread interoperability FUD about competing technology.

Mozilla’s argument that “we really don’t want SQL” is far more troublesome and posts like this follow an increasingly common pattern:

  1. Someone proposes SQL for something (given we’ve got 4 decades of experience with it)
  2. Religious zealots trash talk SQL, offering a dozen or so NoSQL alternatives (all of which are in varying stages of [early] development)
  3. “My NoSQL db is bigger/better/faster than yours” debate ensues
  4. Nobody does anything

Like it or not, SQL is a sensible database interface for web applications today. It’s used almost exclusively on the server side already (except perhaps for the largest of sites, and even these tend to use SQL for some components) so developers are very well equipped to deal with it. It has been proven to work (and work well) by demanding applications including Gmail, Google Docs and Google Calendar, and is anyway independent of the underlying database engine. Ironically work has already been done to provide SQL interfaces to “NoSQL” databases (which just goes to show the “movement” completely misses the point) so those who really don’t like SQLite (which happens to drive most implementations today) could conceivably create a drop-in replacement for it. Indeed power users like myself would likely appreciate a browser with embedded MySQL as a differentiating feature.

In any case the API [cs]hould be versioned so we can offer alternatives like WebSimpleDB in the future. Right now though the open web is being held back by outdated standards and proprietary offerings controlled by single vendors (e.g. Adobe’s AIR and Microsoft’s Silverlight) are lining up to fill in the gap. Those suggesting “it’s worth stepping back” because “there are other options that should be considered” which “might serve those needs better” would want to take a long, hard look at whether their proposed alternatives are really ready for prime time, or indeed even necessary. To an outsider trying to solve real business problems today a lot of it looks like academic wankery.

An open letter to the NoSQL community

Following some discussion on Twitter today I posted this thread to the nosql-discussion group. You can see the outcome for yourself (essentially, and unsurprisingly I might add, “please feel free to take your software and call it whatever you want“).

While I don’t want to mess with their momentum (it’s a good cause, if branded with an unfortunate name) this isn’t the first time the issue’s been raised and I doubt it will be the last. I do however think that “no SQL” is completely missing the point and that the core concern is trading consistency for scalability. At the end of the day developers and users will deploy what is most appropriate for the task at hand.

There’a already been a question about alternatives to SQL, and knowing how Structured Query Language (SQL) came to be (consider the interfaces before it existed and compare that to what we have today) I figure it’s only a matter of time before history repeats itself and we end up creating something like Cloud Query Language (CQL) (a deliberate play on words). The closer this is to ANSI SQL the better it will be, both in terms of technology reuse and of the bags of bones that need to understand how it works… for the same reason the Open Cloud Computing Interface (OCCI) tries very hard to be as close as possible to HyperText Transfer Protocol (HTTP).

———- Forwarded message ———-
From: Sam Johnston
Date: Tue, Oct 27, 2009 at 3:33 PM
Subject: An open letter to the NoSQL community

Afternoon NoSQLers,

I write to you as a huge fan of next generation databases, but also as someone who doesn’t associate in any way with the “NoSQL” moniker. I don’t particularly care for SQL and appreciate the contrived contention it creates, but I think it misses the point somewhat and alienates people like myself who might otherwise have been drawn to the project.

I assume that by “NoSQL” we’re referring to the next generation of [generally cloud-based] databases such as Google’s BigTable, Amazon’s SimpleDB, Facebook’s Cassandra, etc., in which case the issue is more the underlying model (e.g. ACID vs BASE), where we are ultimately trading consistency for scalability.

To me this has nothing to do with the query language (which would still arguably be useful for many applications and which may as well be [something like] SQL, albeit adapted), nor the relational (as opposed to navigational) nature of the data (which is still the case today – it’s just represented as pointers rather than separate “relation” tables), and to focus on either attribute is missing the point. This is particularly true with today’s announcement of Amazon RDS.

Perhaps it’s too late already, but I’d like to think we can come up with a more representative name to which everyone can associate (and which isn’t so scary for fickle enterprise customers). There’s already been a couple of decent suggestions, including alt.db, db-ng, NRDB[MS], etc.