Open
Description
I started using @libsql/client originally as I don't like the blocking nature of better-sqlite3. I am using it with Nuxt and blocking the main thread due to the sync nature, is not something I want longterm.
npm:@libsql/client uses npm:libsql under the hood for non network databases. But it uses the sync api of libsql-js therefore the same problem arises. and as libsql-js has the same api as better-sqlite3 why not choose a more popular library.
And it seems that libsql-js is slower than better-sqlite3
--- reading rows individually ---
better-sqlite3 x 448,189 ops/sec ±1.49%
node-sqlite3 x 39,253 ops/sec ±0.73%
libsql x 224,090 ops/sec ±0.1%
--- reading 100 rows into an array ---
better-sqlite3 x 16,522 ops/sec ±0.13%
node-sqlite3 x 6,771 ops/sec ±0.17%
libsql x 9,996 ops/sec ±0.6%
--- iterating over 100 rows ---
better-sqlite3 x 13,664 ops/sec ±0.12%
node-sqlite3 x 435 ops/sec ±0.69%
libsql x 10,843 ops/sec ±0.22%
--- inserting rows individually ---
better-sqlite3 x 119,189 ops/sec ±1.77%
node-sqlite3 x 33,240 ops/sec ±0.77%
libsql x 95,100 ops/sec ±0.84%
--- inserting 100 rows in a single transaction ---
better-sqlite3 x 9,929 ops/sec ±1.27%
node-sqlite3 x 404 ops/sec ±0.74%
libsql x 3,526 ops/sec ±0.95%
these are the benchmarks from better-sqlite3 modified to add libsql support. the code is just duplicated as the api is the same
Metadata
Metadata
Assignees
Labels
No labels