Async SQLite

[sroussey]

What is the problem this feature would solve?

Move SQLite to its own thread so it does not block the main thread.

Right now SQLite is extra fast because it can skip through promises, etc. Nice for benchmarks! And some workloads. But for others you may want things async so you can do other things while waiting. It is not nice to lock up everything due to a single slow query since this is single threaded.

BTW: I actually have this issue with simple terminal commands that are expected to take a long time, not just a single query but a loop of queries. Since Bun gets locked up (well, the event loop may never run), I can not update the CLI's UI in the terminal while the query runs. This has lots of side-effects in how to code things that are in loops as well... I keep track of how long it has been since the UI has last updated, then force an update if it has been too long. This is the opposite of how to do things where things are async -- I await a promise and I have a timer that updates on an interval and looks at the loop to see how for along it is (using observers in Listr2 for example).

What is the feature you are proposing to solve the problem?

If you create a PHP PDO type abstraction layer for databases, then you could use that interface for an async SQLite that runs in another thread.

What alternatives have you considered?

No response

[Jarred-Sumner]

Yeah, an async SQLite API makes sense here. I think that we will do a bun:sql API that will have multiple adapters under the same API (including sqlite)...but probably not in v0.6

[maxmilton]

You could implement this in user space, once bun supports node:worker_threads. better-sqlite3 has docs for using worker threads and a pull queue mechanism.

See: https://github.com/WiseLibs/better-sqlite3/blob/master/docs/threads.md

[WaveringAna]

whats the status on this looking like?

[Electroid]

Duplicate of #978