Skip to content

Comment on Why IndexedDB is slow and what to use instead

Comments

The conclusion of this article is "do not use IndexedDB as a database", but the reasoning is "if you bulk-insert by creating a transaction for every operation, it's slow".

If you were using IndexedDB as a database, you wouldn't bulk-insert data in this way, as it's the slowest way to do it.

The conclusion should be "use IndexedDB as you would use a database".

It isn't how you would do it if you were bulk loading a bunch of pre determined data, but if it were a bunch of random business transactions in an OLTP scenario that is pretty much how it would happen. The fact that IndexedDB scales poorly in the number of transactions it can handle is an important data point when considering what tech to use.

Well, that hypothetical OLTP database almost certainly has many concurrent clients, right? Your single-threaded JavaScript app is not going to be generating the same usage pattern.

if it were a bunch of random business transactions in an OLTP scenario

Please provide a real world example of this in a client side/PWA context for the class...

I am still trying to figure out why anyone wants a database in their document display program. As far as I am concerned browsers were complete a while ago, and devs are just adding random stuff so they can keep getting a paycheck.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.