Closed fushihara closed 2 months ago
It is intentional here to offer sync APIs only for performance reasons. SQLite unlike other databases, is in-process and does not involve over the network I/O - which we usually do asynchronously. Here, we only have file I/O, and it's really quick most of the times that making it async manually by offloading the work to another thread only introduces more overhead. SQLite3 C API does not offer any asynchronous API. You can always make a new Web Worker, make an SQLite DB instance in that and operate over messages to make it asynchronous and not block the main thread.
Being asynchronous or not is not a matter of being modern. Sometimes, it's just mostly unnecessary to make something asynchronous. The fastest SQLite3 driver for Node.js is better-sqlite3
, it is also sync, and so is bun:sqlite
. All three including this project offer very similar sync API. Is the synchronous API causing any problems in your application?
I did not know that you intentionally provide a synchronous API. I understood that it is a very low priority. I will close the issue for now. Still, I have an idea that I would like to have an asynchronous API, so I will promote the advantages.
Even though file I/O is very fast, throwing heavy queries is a real problem. It is not always correct to make the query a light process, and there are cases where heavy processing is the right answer. If the program is dedicated only to sqlite operations, there is no problem, but since programs usually do a lot of processing, there is a real possibility that they will be dragged down by the synchronous sqlite.
I don't think that being fast in most cases is a reason why the asynchronous API is unnecessary. Do you only use the synchronous API because the file write API is “mostly” fast? I always use the asynchronous API for any light file write.
Thanks!
All the operation APIs are synchronous processes, but I would like to see a modern Promise-based API provided.