After Mozilla’s hacks blog posted an article about how localStorage is too slow and someone else said localStorage is just fine it reminded me of how frustrated I’ve been at the various proposed “solutions” for an in-browser persistence engine. It is completely ridiculous to think it reasonable to have a schema-driven store in the browser. Schema-driven stores work on the server side because engineers can run data migrations and control the flow of data. Browsers are distributed and stateless, there’s no “migration” pattern except one that is roughly lashed on using ugly Javascript conditionals.

At the same time, localStorage simply isn’t enough (though it’s better than schema stores). A pure key value store works for lots of cases but is going to slow down and cause problems with any kind of complex structuring. So what is the solution? I think a document store could make sense: it’s schemaless, simple, and you could write simple querying semantics for it. Maybe a subset of MongoDB’s functionality. But you know what would be perfect? Having Redis in the browser.

Redis gives you a simple key value store with some simple but powerful data structures on top. The interface is dead simple, the values stored are just strings (like localStorage) but with sets, ordered sets, and lists you can implement powerful (and fast) complex logic for an application.

I’m not saying that Redis should literally be ported to the browser as an engine, but I do think that the ideal in-browser store would look almost exactly like Redis. It would be able to set values on keys, have them expire, add values to lists and sets and generally be a “key value store and a little bit more.” Implementation-wise I would imagine that this would be an in-memory store that had the ability (but not the necessity) of flushing to the disk.

Here’s the reasons it would work:

1. Straightforward API: No complex schema migrations, just a simple API that can be used to accomplish powerful things.
2. Small Footprint: Redis, for all its awesomeness, has a very small footprint in terms of complexity of implementation. I believe that something akin to Redis could be taken down the standards path because, unlike WebSQL, it is simple enough for each browser vendor to implement independently.
3. Just Enough Power: SQL is overkill for an in-browser storage layer. Similarly, a document store would be nice to have but would also be overkill for the 95% use case. Redis gives you a simple key value store that can do just enough to cover almost everyone almost all the time.

So Mozilla, Google, Opera (heck, even Microsoft) if you’re looking for an example of a storage API that would match the web browser perfectly, look no further than Redis.