Node.js 24 Built-In SQLite: Replacing better-sqlite3 in Scripts and Edge Workers Without a Native Module
This article was written with the assistance of AI, under human supervision and review.
Most SQLite integration problems in Node.js stem from the gap between needing a simple embedded database and the friction of compiling native modules. Teams reach for better-sqlite3 because it solves the synchronous API problem, but the build step introduces deployment headaches. Cross-compilation breaks. Docker images balloon. Edge worker environments reject native binaries outright.
Node.js 24 ships with node:sqlite, a built-in module that exposes SQLite without requiring a native dependency. The module runs queries, manages transactions, and handles schema migrations using the same synchronous patterns developers already rely on.
The built-in module eliminates the compilation step. Teams write scripts that run immediately on any Node.js 24 runtime without a build phase. Edge workers accept the code because the SQLite engine ships inside the Node.js binary itself.
This matters because deployment complexity compounds. A single native dependency multiplies into platform-specific builds, architecture matrices, and runtime version locks. The built-in module collapses that matrix to zero.
Key Takeaways Node.js 24 includes node:sqlite, a native SQLite module that requires no compilation or external dependencies. The built-in module provides synchronous query execution and transaction support, matching the core API patterns of better-sqlite3. Scripts and edge workers gain immediate compatibility because the SQLite engine ships inside the Node.js binary. Feature gaps exist: better-sqlite3 offers user-defined functions, custom aggregates, and fine-grained performance tuning that node:sqlite does not yet support. Migration paths depend on whether the codebase relies on better-sqlite3's advanced hooks or simply needs basic CRUD and transaction semantics.
Developers adopted better-sqlite3 because the alternative, node-sqlite3, forced asynchronous APIs onto a database that operates synchronously.
SQLite runs on the same thread as the caller. Every query blocks until completion. Wrapping that in Promises or callbacks adds overhead without architectural benefit. The mismatch shows up in transaction code. An asynchronous wrapper turns a three-statement atomic operation into callback nesting or async/await ceremony that obscures the transactional boundary.
better-sqlite3 exposed the synchronous reality directly. Transactions became readable. Statements returned results immediately. The library compiled a native module, but the API aligned with how SQLite actually works.
The compilation requirement created the only friction point. Teams running CI pipelines hit build failures when Python or build-essential packages were missing. Dockerfile layers grew to accommodate the toolchain. Edge environments like Cloudflare Workers rejected the native binary outright.
That tradeoff made sense when no alternative existed. The API clarity justified the deployment cost. Node.js 24 changes the equation by offering synchronous SQLite access without the native module penalty.
The node:sqlite module ships as part of the Node.js standard library. Import it the same way as node:fs or node:path.
The constructor accepts a file path or the special :memory: token for in-memory databases. No options object. No compilation step. The database opens immediately.
Running queries requires preparing a statement and executing it. The two-step pattern prevents SQL injection and allows parameter binding.
The .run() method executes statements that do not return rows. The .all() method retrieves every matching row as an array. The .get() method returns the first row or undefined.
Transactions wrap multiple statements in an atomic block. Roll back if any operation fails.
The API surface matches better-sqlite3 at the statement level. Developers familiar with .prepare(), .run(), and .all() carry that knowledge directly into node:sqlite code. The difference shows up in what the module omits, not in what it changes.