Chromium's IndexedDB implementation is rewritten on top of SQLite, to replace the previous implementation that uses a hybrid of LevelDB and flat files. There is no change to the Web API. This is expected to improve reliability and, to a lesser extent, performance. For now this is applied to *new data stores*. This is step 2 of a multi-phase rollout. See https://chromestatus.com/feature/5126896685809664 which tracks step 1, the rollout for in-memory i.e. incognito contexts. Step 3 will consist of migrating existing data from LevelDB stores to SQLite stores. In this step, the first time a user visits a site, or after clearing site data, new IDB data will be stored in a backend that makes use of SQLite, but existing data stored in LevelDB is unimpacted. See Documentation link below for a list of differences to be aware of.
Chromium's IndexedDB implementation suffers from poor reliability and maintainability because it is highly dependent on a database engine (LevelDB) that is not maintained or supported, or as featureful as a full RDBMS. Many sophisticated web apps report high rates of missing or corrupt data, and bugs in the aging backend are hard to find and fix. SQLite is a more suitable replacement for long-term maintainability as it has an active development team and community, and its features like native support for transactions should yield improved reliability.
Docs: https://docs.google.com/document/d/1S9Rx67BmCZIP7tpasKaQ2FlV4TL1Z15DitR2kRZs9nw/edit?usp=sharing https://docs.google.com/document/d/1-N4NqdYjqaWEbfVPYnCg2Ho1u4YK48pUoQ_tSy9SUg8/edit?usp=sharing
Samples: https://evanstade.github.io/web-storage-demos/idb-txn-scopes