It it's probably possible to work around it by using a separate worker process for the database, but then you're just back to doing things asynchronously. I've considered this for an Electron app, but the synchronous API is actually an issue for a responsive UI. I'm glad somebody finally made a robust synchronous API to sqlite. If you run it in the main thread, it still blocks the renderer process. Make sure to run it in a separate process - never run sqlite in the main thread or the same renderer process as your app. I switched node-sqlite3 with better-sqlite3 in my Electron app and found non-trivial performance gains. I've lightly contributed to both better-sqlite3 and node-sqlite3 and the latter's async implementation makes it much more confusing and difficult to work with. It doesn't make sense at all for CPU work that's going to block it regardless. Async is helpful when you need to wait on something in the future (like new packets come in from a socket) but don't want to block the whole process while waiting. It's definitely a good example of buying into the 'hype' of async without really understanding what's going on. Throwing an async API on top of it is useless - all your doing is making it slower by deferring the computation by a few ticks but when it does run, it's still going to block everything! It's mentioned in other comments but I'm going to repeat it as a top-level comment because it still doesn't seem clear enough to most people: sqlite's C API is synchronous and doesn't use threading, and thus it will always block the node process no matter what.

Nodejs better sqlite3