Currently, there are three competing approaches for saving serious amounts of data (i.e., persistently, and bigger than cookies) locally in your browser:

  1. Web Storage
  2. Indexed Database API
  3. Web SQL Database

These names sure seem similar. But the implementations sure are different. Let's quickly summarize what they do, the PROs and CONs, and what I like best at the moment. Though I'm sure my opinions will age quickly as the technology matures.

All these technologies use the same-origin protection for data access (i.e., javascript can only access data from the url's domain that it was served from), which is fine and not a differentiator so I won't mention that below.

Web Storage

Web Storage, and specifically the localStorage part of it, is a really simple key/value persistence system.

PRO: Really simple API.

PRO: Already available in all major new browsers.

CON: No query language, schemas, really nothing you'd normally call a database. So it wouldn't scale well where you need to impose organization on a larger data set.

CON: They didn't put transactional safety into the standard. I don't think I can sleep at night with an app running that might have race conditions and then have the risk of corrupt data.

Indexed Database API

IndexedDB is basically a simple flat-file database with hierarchical key/value persistence and basic indexing.

PRO: If you're a NoSQL type of person, then this might fit the bill perfectly.

CON: Not yet available in most new browsers.

CON: If you wanted SQL, you're not getting it here. Though in the future, it might be a great building block for implementing a SQL engine for the browser.

Web SQL Database

Web Sql is basically sqlite embedded into the browser. I've used sqlite off-and-on for a few years. At first I was turned off by the name (excuse my superficiality) and by the architecture (just a flat file database). But after digging into it, I found that it's a rock solid platform, and great for production use, as long as you keep in mind its limitations. Its limitations aren't so much size (I think you can go at least 1 GB without a problem), but inherent in flat file databases (high levels of concurrency) and missing features (stored procs and other higher-end database features).

PRO: Fast and pretty feature-rich sql implementation (besides select/insert/update/delete, you can do joins, inner selects, etc).

CON: Available in Chrome and webkit-based browsers (Safari, etc.) but not Firefox or IE.

CON: The darn W3C Working Group has put a hold on the standard since they say they want at least two independent implementations of the standard, and there's only one so far, since everybody is using sqlite.

I wish the standards group would make a special case for sqlite and approve this standard -- it's in the public domain, so it's available to everybody in the world, no strings attached. Sqlite is a perfect fit for browsers - its limitations are not problems. Only one user is using a browser at a time, so no concurrency issues.  And no one wants high-end database features in a simple no-administration database. I think that's why both Android and iOS use sqlite for storage.

Bottom line

If you're only deploying on mobile platforms, then Web SQL is a no-brainer. Or if you're running on desktops and can require Chrome or Safari as your browser, then Web SQL is also for you. I wouldn't use the other two standards in any heavy-duty app at the moment.


Comments

comments powered by Disqus