I'm very excited about libsql both in terms of runtime capabilities as well as properly async rust APIs.
Trying it out, I noticed:
- It doesn't support extensions, which is a known issue:
tursodatabase/libsql#402
- Note that trying to load a sqlite database that was created by rusqlite and extensions loaded, crashed libsql. This one is probably on me?
- Reusing prepared statements requires explicit resets or otherwise the parameters don't bind correctly, see benchmark.
- Some SQL statements that do not typically return rows like PRAGMA need to be queried. Execution leads to "Execute returned rows".
- Even when running in local mode, i.e. plain sqlite3 mode w/o replication capabilities, it's appreciably slower: ~270 times or two orders of magnitude, not percent, at least based on this hopefully flawed benchmark. That said, I'm seeing only 80-90 insertions per second compared to 23k for rusqlite.
FWIW, building and running the benchmarks in debug vs release mode doesn't change much in terms of relative performance.
I haven't (yet) looked into the details of the fork or the execution model of the async client library. That said, I'll share some observations/speculations.
- I suspected lock contention at first, both on the DB as well as the library-level. However inserting sequentially basically leads to the same outcome.
- CPU utilization during execution is incredibly low ~15% of a single core, making me think that most of the time is spent waiting for I/O.