Yes these technologies have been around for several years. Unfortunately none of them are stable/reliable/easy to reason about.
WebSQL (SQLite) has been ignored by Mozilla, on the stated basis that an independent implementation of WebSQL would be too difficult to build. They advocated that a database designed by committee would be better for the web than the most widely deployed database in the world. They deprecated WebSQL before IndexedDB was given a chance to prove itself. Unfortunately they also said that anyone could build SQLite on top of IDB if they chose to. Firefox have implemented IDB on top of SQLite. IDB is at least an order of magnitude slower than SQLite.
LocalStorage is capped at approximately 10mb and there are no quota apis to adjust this. It is not likely that this will change and there has been discussion on the Public Web Apps over whether LocalStorage should also be deprecated in favor of IDB.
ApplicationCache works well but it's designed for caching code and html and it's not an alternative to IDB.
IndexedDB is high-level and "to-do list" friendly. It is not primarily focused on providing library authors with performant low-level storage primitives (BTree, KV) with which to work. The specification is exceedingly complex and so is the API. Chrome has implemented IDB on top of LevelDB which is a terrific storage engine. Exposing something like LevelDB directly would be more useful and make for a powerful, flexible API to boot. IDB has problems with inadvertently capturing application state bubbles. Indexes must be predefined and then migrated at the database layer, the application has no say over indexing. I'm not sure if IDB supports indexing object array values yet. IDB claims to support MVC yet most implementations cause writers to block readers and even readers to block other readers.
Edit:
Mozilla don't plan to support the FileSystem API.
It's not clear that all browsers will provide persistent storage guarantees. At least Mozilla have said that they may treat client-side storage as evict-able at the discretion of the user agent (as opposed to user), rather than as persistent storage. I'm not sure if the specifications have been updated to enforce some kind of guarantee on the part of user agents.
WebSQL (SQLite) has been ignored by Mozilla, on the stated basis that an independent implementation of WebSQL would be too difficult to build. They advocated that a database designed by committee would be better for the web than the most widely deployed database in the world. They deprecated WebSQL before IndexedDB was given a chance to prove itself. Unfortunately they also said that anyone could build SQLite on top of IDB if they chose to. Firefox have implemented IDB on top of SQLite. IDB is at least an order of magnitude slower than SQLite.
LocalStorage is capped at approximately 10mb and there are no quota apis to adjust this. It is not likely that this will change and there has been discussion on the Public Web Apps over whether LocalStorage should also be deprecated in favor of IDB.
ApplicationCache works well but it's designed for caching code and html and it's not an alternative to IDB.
IndexedDB is high-level and "to-do list" friendly. It is not primarily focused on providing library authors with performant low-level storage primitives (BTree, KV) with which to work. The specification is exceedingly complex and so is the API. Chrome has implemented IDB on top of LevelDB which is a terrific storage engine. Exposing something like LevelDB directly would be more useful and make for a powerful, flexible API to boot. IDB has problems with inadvertently capturing application state bubbles. Indexes must be predefined and then migrated at the database layer, the application has no say over indexing. I'm not sure if IDB supports indexing object array values yet. IDB claims to support MVC yet most implementations cause writers to block readers and even readers to block other readers.
Edit:
Mozilla don't plan to support the FileSystem API.
It's not clear that all browsers will provide persistent storage guarantees. At least Mozilla have said that they may treat client-side storage as evict-able at the discretion of the user agent (as opposed to user), rather than as persistent storage. I'm not sure if the specifications have been updated to enforce some kind of guarantee on the part of user agents.