Node.js Built-in SQLite Driver

Node.js applications that need structured persistence without external dependencies can use the built-in node:sqlite module. It exists to give developers a robust relational storage option that does not require installing third-party drivers or managing a separate database server process. By embedding SQLite directly into the runtime, Node.js lets scripts query data using standard SQL while keeping the deployment footprint small.

The mental model

Think of node:sqlite as a built-in bridge between JavaScript and a single-file SQL engine. You open a file handle with DatabaseSync, which creates a direct channel to execute SQL strings and retrieve converted JavaScript values. It is not a network client talking to a remote port; it is an embedded interpreter that reads and writes to a local database file on disk. The module handles translating JavaScript strings, numbers, and booleans into SQLite storage types and back again.

How it works

You import the node:sqlite module and create a DatabaseSync instance by passing a file path. The connection starts via the constructor or an explicit open call. To execute SQL, you have two main paths. First, database.exec runs a raw SQL string directly, which is useful for DDL like CREATE TABLE statements. Second, database.prepare compiles a SQL string into a StatementSync object that you can run multiple times with different parameters. Prepared statements support named parameters and anonymous parameters, and they offer methods like run for inserts and updates, get for a single row, all for every row, and iterate for sequential consumption. Results automatically convert between SQLite types and JavaScript types according to the documented type conversion rules. When finished, you call database.close to release the file handle.

When to use it

Use this module when you need lightweight structured storage without running a separate database server. It excels in command-line tools, local development environments, caching layers, embedded devices, and single-instance applications where a full client-server database would be overkill.

When not to use it

Do not use DatabaseSync in performance-sensitive network servers where query latency would block subsequent operations, because its API is synchronous. It is also unsuitable when you need many concurrent writers across multiple machines, since the module works with a single local file.

One canonical example

A logging CLI tool creates a DatabaseSync instance pointing to logs.db. It uses database.exec to create a table if it does not exist, then prepares an INSERT statement with database.prepare. On each new log entry, it calls statement.run with the timestamp and message as bound parameters, letting SQLite handle persistence and type conversion. When the script exits, it calls database.close to ensure the file handle is released cleanly.