These few words are pointing to a fundamental problem I'm already getting annoyed about, as little as I know about "NoSQL" databases so far: The term NoSQL-database is flawed, just as Fowler says in his introduction talk. Theres's document-oriented databases, and array-ish data storages (column family-oriented), there's graph based databases - and they have very, very different strengths.

The article falls flat on that problem as well. Some data is not relational and you are correct that there is a strong overlap between document based storage systems and relational storage systems. However, I'm dealing with time series data, or with lock-graphs. I could shoe-horn those problems into a relational database, but after tinkering around with better storage engines for my problem... I'd call myself stupid for doing so.

So, as the article says: Use the right tool for the job. And stop calling the tools "SQL" and "NoSQL", those terms are useless.

[1] Actually I said that in my first comment, but the wording is just bad and probably way to sensationalistic. What I really wanted to say is that it is a really bad fit for modeling you usual business with user, orders, products and the like.

Safari, Chrome and Opera implement WebSQL using the public domain SQLite library. This means WebSQL is available on almost all smartphones/tablets and on the majority of PCs.

Btw. Mozilla implemented their "NoSQL" IndexedDB on top of SQLite in the first place. Various features like bookmarks are also stored in a SQLite database. As well as in FirefoxOS.

https://news.ycombinator.com/item?id=7574533

My user's Databases regularly exceed 3 MB.

It's relational data : Serie -> Seasons -> Episodes (sometimes hundreds, sometimes thousands)

Here's a 5MB example: https://dl.dropboxusercontent.com/u/44645464/DuckieTV.sqlite

The project is still in beta, so the database will most likely grow with more tables, easily linking into the existing episodes table with an actors table, for instance.

It's not about SQL it's about a proper relational database with tables, indexes, ACID, etc.

You may remember Google Gears (http://en.wikipedia.org/wiki/Google_Gears ), even back in 2007 one could use the Google Mail (GMail) web interface during a flight, train ride, etc. to read mails, write mails, edit drafts, etc. As soon as the connection had reestablished the data synced between client and server. Later Google rewrote it to HTML5.

There was a trend to move everything to the "cloud". But with the arise of peer-to-peer web applications (WebRTC, etc) and thanks to the bad NSA news we need good client side cache and data storage APIs.

I haven't seen a SQL library as shim on top of IndexedDB. It would be pervert anyway as IndexedDB is implemented on top of SQLite in Firefox.

I would like to ask Mozilla to finally implement WebSQL. With a relational database, more powerful web applications with optional offline support would be possible.

I've just searched for a WebSQL on IndexedDB adapter yesterday and it's certainly possible, but it's a nightmare from the perspective of any sane person. This polyfill I found runs SQLite compiled with CLANG to javascript, which means running 2MB of javascript to support something that they already support 'under the hood'. I refuse to work with that.

https://github.com/Philzen/WebSQL-Polyfill

There is also a similar one called SQL.js - SQLite compiled to JavaScript through Emscripten (probably a big library too): https://github.com/kripken/sql.js

They're meant for situations where you have data that doesn't fit well into a relational database model, and you need to run BIG queries (think PageRank) over the entire data in a fault-tolerant way. For instance thinking about PageRank, how many discrete data elements are in a single web page? This is "higher-order" data that in a relational database might have hundreds or thousands or tens of thousands of columns per row.

Of course there are also in-memory transactional databases called NoSQL databases which are meant to be replacements for the traditional relational data store, but those are a very different beast from the original NoSQL data model.

Change your entity? Regenerate the wrapper and generate a migration.

Problem still is: Nobody is writing tooling for WebSQL. Everybody just seems to automatically grab NoSQL, throwing away 30 years of built up software developing knowledge, including the golden rules of Database Normalisation: Don't duplicate your data, and compartmentalize.

  > The NoSQL data model - please read as document oriented
  > is fundamentally flawed because it forces you into 
  > denormalization...

Start anywhere, for example, pick your users and create a document for each. Now you take the orders of each user and also put them into the document belonging to the respective user. Fine, that works. Now we come to the products they ordered, and now we have a problem. Unless no product has ever been ordered by two different users we have to duplicate product information and put it into several different documents. And there is the same problem within documents if the user repeatedly ordered the same product.

All interesting problem domains just don't fit the idea of piece of JSON without references, internally or externally. There is of course support for reference in document oriented databases, but then lets just call your documents rows in a table and your references foreign keys and we are almost back at the relational model besides that documents still have a richer model, a bit like a NF² relational model or database with deep support for XML or JSON columns.

  > Now you take the orders of each user and also put them 
  > into the document belonging to the respective user.

  > All interesting problem domains just don't fit the idea 
  > of piece of JSON without references, internally or 
  > externally.

I am not saying there are no usecases where a document oriented model fits well, but I argue that it is not a good fit for modeling your average business.

Haven't scaled it yet, though...

Try out Couchbase Mobile http://mobile.couchbase.com and compare it to best of breed relational sync.

My own little WebSQL Object/Relation mapping library uses promises to get away from callback hell, and it's a pure joy to work with.

It handles creating tables and inserting fixtures before the first connect promise is returned, so that you don't have to worry about the setup process and your data being available.

Creating and inserting entities is as easy as

  > var P = new Presentation();
  > P.set('name', 'test');
  > P.Persist().then(function(result) { console.log('Done!') });

I'm using it extensively in my Chrome plugin, and it runs on 10.000+ clients right now.

Real world offline synchronisation example right here:

https://github.com/SchizoDuckie/DuckieTV/blob/angular/js/ser...

Sadly one cannot use it everywhere as WebSQL is not implemented in Firefox nor IE :(

The good thing is WebSQL works also great on mobile devices.

In the other hand, I'm stuck in how sync with a relational model :(

So, it sync well and broke my relations and transactions or it sync hard but keep my data correct.