HTML5 IndexedDB, Web SQL Database and browser wars

Question

I'm starting the development of a web app with offline database storage requirements. Long story short, the app should be able to run on:

• One of the major desktop browsers, Chrome preferred
• Safari on iOS
• Android's native browser (based on V8 and WebKit)

So the question is which technology to choose: IndexedDB or Web SQL Database?

Regarding Web SQL Database, on one hand, it is ready to be used in any of the above scenarios. On the other, Mozilla has stated Firefox will never implement it, and acording to the HTML5 working draft the specification has reached an impasse:

This specification has reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path. Until another implementor is interested in implementing this spec, the description of the SQL dialect has been left as simply a reference to Sqlite, which isn't acceptable for a standard. Should you be an implementor interested in implementing an independent SQL backend, please contact the editor so that he can write a specification for the dialect, thus allowing this specification to move forward.

IndexedDB is the alternative advocated by Mozilla, but it will only come in Firefox 4. Microsoft is interested and Chrome will support it as well. I know nothing of Apple's plans regarding IndexedDB.

I'm personally inclined to choose Web SQL Database, but just because I'm used to SQLite, I like the power and expressiveness of SQL, and I understand the relational model. IndexedDB, for me, is an uncertainty.

That said, I'm afraid of betting on the wrong horse. Is it safe to assume support for Web SQL Database will continue to exist, even if IndexedDB becomes the standard?

(A note on CouchDB: do you also see it as an alternative?)

Answer 1

Considering only WebSQL supports all three requirements you have listed, shouldn't your choice be simple? You have no insight into the development roadmap for Safari or Android, so use what you have available.

Answer 2

Are your database needs significantly beyond key/value stores? If not, I've found a number of javascript packages for local browser-based database abstraction. One such package is jStore:

http://code.google.com/p/jquery-jstore/

I recently used it to add local key/value storage. It's well-documented and the integration time was negligible -- it supports an array of storage backends, including flash local storage, through its API.

CouchDB is an excellent solution -- for a problem that is not quite congruent with yours. Check out couchone mobile. Not for strictly 'web apps' but it may provide a database foundation you could run with, if you have some flexibility with the specification.

Answer 3

Well, as with all things computing, the game is "abstraction".

If you can come up with an adequate layer that works on both a SQL store and a key/value store, then, ideally you're isolated from the problem and can support the appropriate implementation on the particular browser. If your data model and access patterns don't fit with the lowest common denominator (i.e. a k/v store), then that pretty much solves your problem right there.

If you can use either store, then work on a decent access layer and approach the problem from that direction.

Mind, just because you have a k/v store on the back end doesn't mean you have to model your data as only a k/v model. Essentially all a DB is on the backend is a k/v store. If you don't have an insane amount of data, you can do many things. With a large amount of data the hoops you might have to jump through may cost you in performance that you may well not see with a smaller amount of data. All depends.