2 ms·

IndexedDB's ugliness is due to being from a time before ES6+ really kicked into gear and we still had the old crud of weird callback stacks (See FileReader for

IndexedDB's ugliness is due to being from a time before ES6+ really kicked into gear and we still had the old crud of weird callback stacks (See FileReader for another example). As for SQLite, as lovely as that'd be, NOONE wanted to spend R&D on building a "SQLite clone" for the web SQL spec, and I can't blame them, how the hell can you justify that effort when SQLite exists and is crazy well tested and proven?

hajile 5y ago
Have you ever tried to use it on a project? It's been a while for me as I moved to PouchDB or SQLite in WASM and never looked back. Let's say you need to search for age > 19 and less than 30 for a person with the name of Jane or John. That's nothing complicated, but indexedDB CANNOT DO THIS. I suppose you could do it by iterating every single data entry, but that's a performance no-go for even relatively trivial databases. Likewise, joins on different stores simply don't exist. Iterating every entry in this case is O(N^2). Might as well just store a giant JSON blob instead. Quite literally, my only use of indexedDB these days is storing a SQLite file and whatever interactions PouchDB has (I think they are mostly limited to linking an ID with a JSON blob). Adding insult to injury, despite being a simple key/val store, it's SLOWER than SQLite too.
- comex 5y ago
  > Let's say you need to search for age > 19 and less than 30 for a person with the name of Jane or John. I’m pretty sure you can do that. You can create an IDBIndex that covers multiple fields, then narrow down the search using key ranges. Though, even with key ranges, narrowing down results based on multiple independent ranges requires some manual work: https://gist.github.com/inexorabletash/704e9688f99ac12dd336 https://gist.github.com/inexorabletash/704e9688f99ac12dd336 But at least algorithmically speaking, that’s roughly the same thing that a database natively supporting such queries would be doing, so the big-O performance should be the same. Though I wouldn’t be surprised at all if it’s slower in practice.

hajile 5y ago

Have you ever tried to use it on a project? It's been a while for me as I moved to PouchDB or SQLite in WASM and never looked back. Let's say you need to search for age > 19 and less than 30 for a person with the name of Jane or John. That's nothing complicated, but indexedDB CANNOT DO THIS. I suppose you could do it by iterating every single data entry, but that's a performance no-go for even relatively trivial databases. Likewise, joins on different stores simply don't exist. Iterating every entry in this case is O(N^2). Might as well just store a giant JSON blob instead. Quite literally, my only use of indexedDB these days is storing a SQLite file and whatever interactions PouchDB has (I think they are mostly limited to linking an ID with a JSON blob). Adding insult to injury, despite being a simple key/val store, it's SLOWER than SQLite too.

comex 5y ago
> Let's say you need to search for age > 19 and less than 30 for a person with the name of Jane or John. I’m pretty sure you can do that. You can create an IDBIndex that covers multiple fields, then narrow down the search using key ranges. Though, even with key ranges, narrowing down results based on multiple independent ranges requires some manual work: https://gist.github.com/inexorabletash/704e9688f99ac12dd336 https://gist.github.com/inexorabletash/704e9688f99ac12dd336 But at least algorithmically speaking, that’s roughly the same thing that a database natively supporting such queries would be doing, so the big-O performance should be the same. Though I wouldn’t be surprised at all if it’s slower in practice.