Exploring indexedDB

I’m playing with indexedDB and will post a series of articles on what I find. In this first one, let’s look at indexedDB’s structure.

Overview of indexedDB


IndexedDB stores your data in a database. Databases are protected: an application from one website cannot access a database from another’s. How does the browser differentiate between them? If all elements of the application’s origin match, access is granted; otherwise it is denied. The origin is the combination of protocol, hostname and port, for example:


is a different origin from


and both are different from either of these:



A database has a name and a version number. The name must be unique within that origin. The version number enables you to enhance your application to use an updated data model, and to roll this new update out across existing clients that have been using an older model, thus upgrading their database when they next use your application.

Object Store

A database contains at least one object store. An object store holds records as key-value pairs. Keys, which are unique within an object store, can be arrays, strings, dates or numbers, and can be auto-generated.

The object store is organised by key in ascending order: numbers first, then dates, then strings, and finally arrays.

Values can be any JavaScript object.

Asynchronous Programming Model

We’ll focus on IndexedDB’s asynchronous API. Here’s an analogy: imagine that you’ve taken your car to be repaired. Your car goes into a queue, and the receptionist gives you a pre-pay mobile phone that she says she will call you back on when your car is ready or if there is a problem. Further, she also tells you that the phone comes with an app that you can instruct yourself: you can instruct it to do this or that depending on whether the car was fixed (‘onsuccess’) or not (‘onerror’). If there was a problem, you can find out what the problem was.

The IndexedDB Asynchronous API works like this:

IndexedDB's Asynchronous API

  1. You call IndexedDB; every call returns immediately, without blocking the caller’s thread.
  2. Your call returns a request object (the mobile phone).
  3. You set up event handlers (‘onsuccess’ and ‘onerror’) on the request object.
  4. Once information is available, IndexedDB will fire events on the request object, resulting in calls to your handlers.

That’s all for now. More to come shortly.



This entry was posted in Uncategorized by peter. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


HTML tags are not allowed.