What are the tradeoffs between sql.js and IndexedDB?

[githorse]

The obvious and official solution for SQL-like functionality in the browser is now IndexedDB. Could the docs address the tradeoffs between sql.js and IndexedDB (including performance on large datasets)?

[lovasoa]

IndexedDB is not really SQL - like. If your use case is simple enough to be handled easily with IndexedDB, use IndexedDB. If you need SQL, go with sql.js.

[githorse]

@lovasoa Yes, that much I know. But I am a smart guy and I can probably make my code work either way. The question is, what are the tradeoffs? (One obvious one is that IndexedDB is persistent, while (raw) sql.js is not. What else should I be considering? What about the performance of some average queries across large datasets -- is there a benchmark?)

If the maintainers of sql.js are not interested in helping users understand these tradeoffs, perhaps someone else from the community can point me to a resource that covers this in more detail?

[milahu]

what are the tradeoffs

IndexedDB: on-disk, slow, no query language
sql.js: in-memory, fast, SQL query language

ideally, sql.js should support IndexedDB as a storage backend, to reduce memory usage

• Allow hooking into the filesystem and providing a persistent backend (like absurd-sql) #481
• absurd-sql - sql.js with an IndexedDB storage backend - also has benchmarks IndexedDB vs sql.js
• Meta VFS for adding storage options #447