IndexedDB is a key/value store; DuckDB is a relational analytic database. You would use IndexedDB for something like application data, and DuckDB for (e.g.) a data-heavy dashboard or ad-hoc query tool.
So what? We should be structuring a lot of databases as layers on top of transactional key value stores. We should be able to swap out the key value store without changing the higher level query engine.
We maybe[1] should, but we are not. AFAIK there's no relational query engine for IndexedDB.
Also, there are a lot more people who can get things done with SQL than using indexed KV-stores. KV stores tending to have horrible APIs doesn't help the situation.
[1] E.g. SQLite started with a gdbm backend, but later rolled their own because of limitations caused by it.
Comments
IndexedDB is a key/value store; DuckDB is a relational analytic database. You would use IndexedDB for something like application data, and DuckDB for (e.g.) a data-heavy dashboard or ad-hoc query tool.
You can leverage SQL on top of IndexedDB by using AlaSQL (https://github.com/AlaSQL/alasql) or absurd-sql (https://github.com/jlongster/absurd-sql).
So what? We should be structuring a lot of databases as layers on top of transactional key value stores. We should be able to swap out the key value store without changing the higher level query engine.
We maybe[1] should, but we are not. AFAIK there's no relational query engine for IndexedDB.
Also, there are a lot more people who can get things done with SQL than using indexed KV-stores. KV stores tending to have horrible APIs doesn't help the situation.
[1] E.g. SQLite started with a gdbm backend, but later rolled their own because of limitations caused by it.
There is SQL on top of IndexedDB: absurd-sql or AlaSQL.
When you build that, I will upvote the HN post to that too ;)
Don't tempt me. :-) This is what SQLite 4 was supposed to have been, BTW.