Is SQLite fit as a backend for KV?

[petamoriken]

The unstable key-value store is implemented in SQLite now, however there are more lightweight and better performing key-value store backends.

Why not choose a better one, like Chrome stopped using SQLite and developed LevelDB for IndexedDB?

[losfair]

LSM-tree backends like LevelDB or RocksDB are generally heavier than SQLite, both in binary size and runtime overhead. For example, they need to spawn a thread for merging the parts in the background.

[Leokuma]

There's a nice comparison here: https://www.slideshare.net/InsightTechnology/dbtstky2017-c23-sqlite

SQLite4 (now dead) tried to follow the LSM path.

Highlights:

Many people believe:

• B-tree = slow and bad
• LSM = fast and good

But the truth is more complicated…..

Lessons

• SQLite3 is already very fast and hard to beat
• LSM is great for “blind” writes, but does not work as well when constraints must be checked
  prior to each write
• Many workloads do more reading than writing

[lino-levan]

SQLite is fast. I was in a talk by Dr. Hipp regarding his continued work on SQLite and people don't fully appreciate how optimized the performance really is. If you send him an email with a slow query, he often is willing to spend some time trying to optimize SQLite for your query (happened for me a couple of times).

[alexgleason]

Related: #18975

There's already a very good lmdb-js, which the author states has "pretty direct mappings" to Deno.KV

[Leokuma]

Resources:

• Mozilla's comparison between LevelDB and LMDB: https://mozilla.github.io/firefox-browser-architecture/text/0017-lmdb-vs-leveldb.html
• Badger's comparison between BoltDB, LMDB and Badger: https://dgraph.io/blog/post/badger-lmdb-boltdb/
• LMDB's author comparison between LevelDB and LMDB: https://www.symas.com/post/is-lmdb-a-leveldb-killer

Heed is the LMDB wrapper for Rust recommended by LMDB's author.

I'm just worried that I found lots of dead repos with stale issues related to LMDB.