It depends on what you mean by atomic. Please refer to http://www.chromium.org/developers/design-documents/indexeddb/indexeddbbackup http://www.chromium.org/dev

It depends on what you mean by atomic. Please refer to http://www.chromium.org/developers/design-documents/indexeddb/indexeddbbackup http://www.chromium.org/developers/design-documents/indexedd... where Chromium devs state: """ LocalStorage is inherently racy or a parallelism disaster, depending on whether or not you're willing to implement the "storage mutex" described in the spec. Chromium has decided not to implement it. WebKit itself is single thread/process (i.e. no parallelism period). """ Note that the way Chromium implements localStorage, it uses a disk backing store of sqlite, a caching layer (a std::map) in the browser process, and a caching layer (also a std::map) in the renderer processes (where WebKit runs, and may handle 1-X tabs per process). Changes are propagated via IPC, but as the API does not provide any locking guarantees beyond the optional storage mutex, which Chromium does not implement, there are obviously race conditions. This probably explains the issues the author of that post encountered with Chrome.