Adds a commit() function to IDBTransaction objects, which explicitly marks a transaction as not accepting further requests. Currently, IndexedDB only commits a transaction after all associated requests have had their completion event handlers executed, and no new requests have been queued by the event handlers. Developers can use the explicit commit() function to shave a few event loop cycles off of the latency of their transactions.


Specification link

Specification being incubated in a Community Group

Status in Chromium


Enabled by default (tracking bug)

Consensus & Standardization

After a feature ships in Chrome, the values listed here are not guaranteed to be up to date.


Intent to Prototype url

Intent to Prototype thread


The primary benefit of the explicit commit functionality is that it will increase the throughput of read and write requests made on an object store. This is a clear performance benefit in terms of the rate at which operations can be processed, and the increase in speed is additionally advantageous because it adds stability to IndexedDB by reducing the probability that a disruptive event occurs within the lifetime of a transaction. To provide a particular use case, the explicit commit() functionality is critical for allowing the Lifecycle API to use IndexedDB as the backing store of choice when saving tab state. Presently developers must use localStorage when saving tab state on shutdown because IndexedDB’s autocommit flow does not have guarantees as strong as those of localStorage when it comes to ensuring that data will still be written to disk even in the event that a tab is shut down before the data is actually finished writing. IndexedDB is a much more well-behaved database in most other respects, so allowing the Lifecycle API to rely on IndexedDB rather than localStorage will be a marked improvement. See:

Search tags

indexeddb, commit, transaction,

Last updated on 2021-12-13