IndexedDB is just SQLite in disguise or isn’t it?
Recently IndexedDB started to be not the best choice for our scenario. We wanted something relational. I heard that the IndexedDB is just a layer of abstraction on top of SQLite. Of cause, we have libraries like absurd-sql. But looks like you are going to use SQLite over IndexedDB over SQLite. Of cause, we do not have access to underlying browser-specific implementations. Still, it doesn’t hurt to find out more.
- For Mozilla, we can visit https://github.com/mozilla/gecko-dev/tree/master/dom/indexedDB and find out a lot of SQLite references in the codebase. F.i.
// By default IndexedDB uses SQLite with PRAGMA synchronous = NORMAL. This // guarantees (unlike synchronous = OFF) atomicity and consistency, but not // necessarily durability in situations such as power loss. This preference // allows enabling PRAGMA synchronous = FULL on SQLite, which does guarantee // durability, but with an extra fsync() and the corresponding performance // hit.2. For Chrome, open https://github.com/chromium/chromium/tree/c4d3c31083a2e1481253ff2d24298a1dfe19c754/content/browser/indexed_db and find out that there is no reference to SQLite, but a lot to LevelDb. Indeed Chrome uses LevelDb undercover. You can read more about it at https://www.cclsolutionsgroup.com/post/indexeddb-on-chromium.
3. For WebKit, we can check out https://github.com/WebKit/WebKit/tree/main/Source/WebCore/Modules/indexeddb/server and find SQLite. And LevelDb was removed a long time ago. So it’s 2 out of 3 major browser engines use SQLite.
Still, one of the motives of IndexedDB creating —getting rid of SQL in Web. So after all it seems reasonable not to focus on underlying IndexedDB realization and use another layer of abstraction on top of IndexedDB.
References:
