It's buggy depending on browser implementation, Firefox will corrupt DBs, it's a herculean task to debug things with users, it blocks the main thread for reads or writes (maybe wasm stuff does too).

Wow this is so embarrassing as hell. Apparently even using a WebWorker can still cause the UI to block when talking to indexeddb. https://nolanlawson.com/2015/09/29/indexeddb-websql-localsto... https://issues.chromium.org/issues/41204713#comment28

It's crazy how much effort goes into adding new things to the web but stuff like this is almost 10 years old.

It has a weird, verbose API that's more like a simple document store than a SQL database, so it's naturally going to be outperformed by SQLite, especially if you're performing complex operations. It's also heavily async which means operations have to spin the event loop.

yeah I gave up on the direct API, I used Dexie for my product.

I think it's funny you say a problem is that it's async while another commentor says a problem is it blocks the UI. Maybe it's the worst of both?

Yes, it's the worst of both. Dexie is at the mercy of the aforementioned issues with IDB (differing browser implementations, async APIs while blocking of the main thread, hard to debug, can't actually guarantee persistence beyond "best effort"). The issues are much more prevalent on mobile browsers in our experience (iOS Safari in particular being the worst), to the point I think we'll need to move off it for our persistence layer in our own app and will unfortunately be forced to require our users to download wrapped apps (Capacitor and Electron) if they want offline persistence guarantees.

But yes, the Dexie API is indeed a much better experience for working with IDB.