Database language wars and web browsers

The web browser community is preparing to re-live the database language wars of the 1980's. Nowadays it's hard to remember what the world was like in the 1980's before SQL was the standard and every vendor implemented at least some version of it. Back in the 1980's, each DBMS vendor tended to have its own language: DB2 and Oracle had SQL, but Ingres had QUEL, ADABAS had NATURAL, Model204 had User Language, IDMS had Online English (I think), Cincom had TOTAL, ADR DATACOM had their own language, and so forth.

It was, put simply, a mess.

Near the end of the 1980's it became clear that SQL had won, and all the other database vendors conceded, and built SQL language interfaces to their systems. All modern DBMS implementations use some form of SQL as their API, and most adhere quite closely to the SQL standards, though there continue to be too many standards and too many inconsistencies.

Now, along come the browser vendors, trying to figure out how to enable persistent local storage for applications that run inside the web browser.

One branch of this effort is Firefox 2's Local Storage, which has become Web Storage, a persistent key-value local storage system.

But local storage has very little in the way of data structuring and query structuring (structuring, of course, is the "S" in SQL...), so the clamor has arisen for providing some sort of "true" database storage layer for web browser-based applications. Why not use SQL? It's well-known, proven, powerful. Indeed, this was the direction that things seemed to be heading, as Safari, Google Gears, and other systems started providing SQL-style APIs for browser-based applications. But this approach did not find favor at Mozilla:

at Mozilla we've felt that exposing SQL directly to the web, with all of its incompatibilities and under-specification is likely to cause huge amounts of pain down the road for developers as incompatible versions emerge each with very different performance characteristics.

So what is Mozilla's alternate suggestion? Over the weekend, they set it out, in a pair of postings.

In the first article, they explain more about their concerns with SQL, and why they sought an alternative:

despite the ubiquity that SQL enjoys, there isn’t a single normative SQL standard that defines the technology
...
In order to really get Web SQL Database right, we’d have to first start with defining a meaningful subset of SQL for web applications. Why define a whole other language, when more elegant solutions exist within JavaScript itself?

I'm not really sure why Mozilla don't believe that a SQL standard exists, and adquately defines the technology. SQL-92, after all, has been available for nearly 20 years, and is, if not perfect, surely one of the better-known standards in the computing world. In fact, the strongest argument for using SQL is precisely to avoid the mistake of "defin[ing] a whole other language". But maybe I'm misunderstanding Mozilla's complaint. Perhaps it isn't that they are opposed to SQL, or to SQL-92. Perhaps it is that they are frustrated because SQLite, the current implementation of choice among other browser vendors, doesn't actually implement SQL-92, or any other well-known variant of the SQL standard, but instead implements its own generally-similar, but not actually standards-compliant, query language. If that's Mozilla's complaint, then I agree 100%; I too am frustrated by SQLite's co-opting of the SQL terminology without implementing a standard SQL system. Whatever SQLite is, it isn't SQL. If any group deserves some heat for defining "a whole other language", it should be SQLite, and I think it's a shame that their early success in getting vendors like Apple and Google to accept their technology has made it so hard to critique and improve their offering.

In their second article, the Mozilla team go on to describe their preferred alternative, which is to get behind the Indexed Database API, a new web browser standard coming out of the W3C. The Mozilla team say:

As a counter-point, both Microsoft and Mozilla have expressed interest in the indexed sequential storage API edited by Oracle's Nikunj Mehta as a more logical choice for indexed databases on the web than existing SQL API implementations. It's a pretty simple API that is low level and is targeted at library developers who can build database tools around it, including implementations like SQL or CouchDB.

The Mozilla team describe their experiences at a developer "summit", where

We watched as developers whiteboarded a simple BTree API that addressed their application storage needs, and this galvanized us to consider other options. We were resolved that using strings representing SQL commands lacked the elegance of a “web native” JavaScript API, and started looking at alternatives.

Well, good luck, browser world. I'm afraid that I know from 30 years experience that inventing database query languages is a hard business, even if everybody seems to want to do it. I'm afraid I have a sad feeling about what's going to happen when a group of people from Mozilla, Google, Microsoft, and Oracle get together to try to define the brave new query language for the brave new world of structured data storage in the browser. Hopefully I am being too pessimistic about this, and these folks will be successful, and their query language will be powerful, useful, and widely adopted.