SQLite

<!--introduced_in=v22.5.0-->

<!-- YAML added: v22.5.0 changes: - version: v25.7.0 pr-url: https://github.com/nodejs/node/pull/61262 description: SQLite is now a release candidate. - version: - v23.4.0 - v22.13.0 pr-url: https://github.com/nodejs/node/pull/55890 description: SQLite is no longer behind --experimental-sqlite but still experimental. -->

Stability: 1.2 - Release candidate.

<!-- source_link=lib/sqlite.js -->

The node:sqlite module facilitates working with SQLite databases. To access it:

import sqlite from 'node:sqlite';
const sqlite = require('node:sqlite');

This module is only available under the node: scheme. SQL trace events can be observed via the [diagnostics_channel][] module. See ['sqlite.db.query'][] for details.

The following example shows the basic usage of the node:sqlite module to open an in-memory database, write data to the database, and then read the data back.

import { Database } from 'node:sqlite';
const database = new Database(':memory:');

// Execute SQL statements from strings.
database.exec(`
  CREATE TABLE data(
    key INTEGER PRIMARY KEY,
    value TEXT
  ) STRICT
`);
// Create a prepared statement to insert data into the database.
const insert = database.prepare('INSERT INTO data (key, value) VALUES (?, ?)');
// Execute the prepared statement with bound values.
insert.run(1, 'hello');
insert.run(2, 'world');
// Finalize the prepared statement once it is no longer needed.
insert.close();
// Create a prepared statement to read data from the database.
const query = database.prepare('SELECT * FROM data ORDER BY key');
// Execute the prepared statement and log the result set.
console.log(query.all());
// Prints: [ { key: 1, value: 'hello' }, { key: 2, value: 'world' } ]
query.close();
const { Database } = require('node:sqlite');
const database = new Database(':memory:');

// Execute SQL statements from strings.
database.exec(`
  CREATE TABLE data(
    key INTEGER PRIMARY KEY,
    value TEXT
  ) STRICT
`);
// Create a prepared statement to insert data into the database.
const insert = database.prepare('INSERT INTO data (key, value) VALUES (?, ?)');
// Execute the prepared statement with bound values.
insert.run(1, 'hello');
insert.run(2, 'world');
// Finalize the prepared statement once it is no longer needed.
insert.close();
// Create a prepared statement to read data from the database.
const query = database.prepare('SELECT * FROM data ORDER BY key');
// Execute the prepared statement and log the result set.
console.log(query.all());
// Prints: [ { key: 1, value: 'hello' }, { key: 2, value: 'world' } ]
query.close();

Type conversion between JavaScript and SQLite

When Node.js writes to or reads from SQLite, it is necessary to convert between JavaScript data types and SQLite's [data types][]. Because JavaScript supports more data types than SQLite, only a subset of JavaScript types are supported. Attempting to write an unsupported data type to SQLite will result in an exception.

Storage class JavaScript to SQLite SQLite to JavaScript
NULL {null} or {undefined} {null}
INTEGER {number}, {bigint}, or {boolean} {number} or {bigint} (configurable)
REAL {number} {number}
TEXT {string} {string}
BLOB {TypedArray}, {DataView}, {ArrayBuffer}, or {SharedArrayBuffer} {Uint8Array}

Booleans are written as the INTEGER values 1 and 0. Like any other INTEGER value, they are read back as {number} by default, or as {bigint} values (1n and 0n) when reading BigInts is enabled. Writing a {bigint} that does not fit in a signed 64-bit integer throws an ERR_INVALID_ARG_VALUE error.

undefined is written as NULL, so passing it explicitly is equivalent to omitting a named parameter. NULL always reads back as {null}, never undefined.

APIs that read values from SQLite have a configuration option that determines whether INTEGER values are converted to number or bigint in JavaScript, such as the readBigInts option for statements and the useBigIntArguments option for user-defined functions. If Node.js reads an INTEGER value from SQLite that is outside the JavaScript [safe integer][] range, and the option to read BigInts is not enabled, then an ERR_OUT_OF_RANGE error will be thrown.

Class: Database

<!-- YAML added: v22.5.0 changes: - version: - v24.0.0 - v22.16.0 pr-url: https://github.com/nodejs/node/pull/57752 description: Add timeout option. - version: - v23.10.0 - v22.15.0 pr-url: https://github.com/nodejs/node/pull/56991 description: The path argument now supports Buffer and URL objects. -->

This class represents a single [connection][] to a SQLite database. All APIs exposed by this class execute synchronously.

DatabaseSync is a deprecated alias for Database, kept for backward compatibility with the class's previous name. See [DEP0210](https://nodejs.org/docs/latest/api/deprecations.md#dep0210-sqlitedatabasesync.

new Database(path[, options])

<!-- YAML added: v22.5.0 changes: - version: - v25.5.0 - v24.14.0 pr-url: https://github.com/nodejs/node/pull/61266 description: Enable defensive by default. - version: - v25.1.0 - v24.12.0 pr-url: https://github.com/nodejs/node/pull/60217 description: Add defensive option. - version: - v24.4.0 - v22.18.0 pr-url: https://github.com/nodejs/node/pull/58697 description: Add new SQLite database options. -->

  • path {string | Buffer | URL} The path of the database. A SQLite database can be stored in a file or completely [in memory][]. To use a file-backed database, the path should be a file path. To use an in-memory database, the path should be the special name ':memory:'.
  • options {Object} Configuration options for the database connection. The following options are supported:
  • open {boolean} If true, the database is opened by the constructor. When this value is false, the database must be opened via the open() method. Default: true.
  • readOnly {boolean} If true, the database is opened in read-only mode. If the database does not exist, opening it will fail. Default: false.
  • enableForeignKeyConstraints {boolean} If true, foreign key constraints are enabled. This is recommended but can be disabled for compatibility with legacy database schemas. The enforcement of foreign key constraints can be enabled and disabled after opening the database using [PRAGMA foreign_keys][]. Default: true.
  • enableDoubleQuotedStringLiterals {boolean} If true, SQLite will accept [double-quoted string literals][]. This is not recommended but can be enabled for compatibility with legacy database schemas. Default: false.
  • allowExtension {boolean} If true, the loadExtension SQL function and the loadExtension() method are enabled. You can call enableLoadExtension(false) later to disable this feature. Default: false.
  • timeout {number} The [busy timeout][] in milliseconds. This is the maximum amount of time that SQLite will wait for a database lock to be released before returning an error. Default: 0.
  • readBigInts {boolean} If true, integer fields are read as JavaScript BigInt values. If false, integer fields are read as JavaScript numbers. Default: false.
  • returnArrays {boolean} If true, query results are returned as arrays instead of objects. Default: false.
  • allowBareNamedParameters {boolean} If true, allows binding named parameters without the prefix character (e.g., foo instead of :foo). Default: true.
  • allowUnknownNamedParameters {boolean} If true, unknown named parameters are ignored when binding. If false, an exception is thrown for unknown named parameters. Default: false.
  • defensive {boolean} If true, enables the defensive flag. When the defensive flag is enabled, language features that allow ordinary SQL to deliberately corrupt the database file are disabled. The defensive flag can also be set using enableDefensive(). Default: true.
  • limits {Object} Configuration for various SQLite limits. These limits can be used to prevent excessive resource consumption when handling potentially malicious input. See [Run-Time Limits][] and [Limit Constants][] in the SQLite documentation for details. Default values are determined by SQLite's compile-time defaults and may vary depending on how SQLite was built. The following properties are supported:
    • length {number} Maximum length of a string or BLOB.
    • sqlLength {number} Maximum length of an SQL statement.
    • column {number} Maximum number of columns.
    • exprDepth {number} Maximum depth of an expression tree.
    • compoundSelect {number} Maximum number of terms in a compound SELECT.
    • vdbeOp {number} Maximum number of VDBE instructions.
    • functionArg {number} Maximum number of function arguments.
    • attach {number} Maximum number of attached databases.
    • likePatternLength {number} Maximum length of a LIKE pattern.
    • variableNumber {number} Maximum number of SQL variables.
    • triggerDepth {number} Maximum trigger recursion depth.

Constructs a new Database instance.

database.aggregate(name, options)

<!-- YAML added: - v24.0.0 - v22.16.0 -->

Registers a new aggregate function with the SQLite database. This method is a wrapper around [sqlite3_create_window_function()][].

  • name {string} The name of the SQLite function to create.
  • options {Object} Function configuration settings.
  • deterministic {boolean} If true, the [SQLITE_DETERMINISTIC][] flag is set on the created function. Default: false.
  • directOnly {boolean} If true, the [SQLITE_DIRECTONLY][] flag is set on the created function. Default: false.
  • useBigIntArguments {boolean} If true, integer arguments to options.step and options.inverse are converted to BigInts. If false, integer arguments are passed as JavaScript numbers. Default: false.
  • varargs {boolean} If true, options.step and options.inverse may be invoked with any number of arguments (between zero and [SQLITE_MAX_FUNCTION_ARG][]). If false, inverse and step must be invoked with exactly length arguments, and their length properties must be integers. Default: false.
  • start {number | string | null | Array | Object | Function} The identity value for the aggregation function. This value is used when the aggregation function is initialized. When a {Function} is passed the identity will be its return value.
  • step {Function} The function to call for each row in the aggregation. The function receives the current state and the row value. The return value of this function should be the new state.
  • result {Function} The function to call to get the result of the aggregation. The function receives the final state and should return the result of the aggregation.
  • inverse {Function} When this function is provided, the aggregate method will work as a window function. The function receives the current state and the dropped row value. The return value of this function should be the new state.

When used as a window function, the result function will be called multiple times.

const { Database } = require('node:sqlite');

const db = new Database(':memory:');
db.exec(`
  CREATE TABLE t3(x, y);
  INSERT INTO t3 VALUES ('a', 4),
                        ('b', 5),
                        ('c', 3),
                        ('d', 8),
                        ('e', 1);
`);

db.aggregate('sumint', {
  start: 0,
  step: (acc, value) => acc + value,
});

using query = db.prepare('SELECT sumint(y) as total FROM t3');
query.get(); // { total: 21 }
import { Database } from 'node:sqlite';

const db = new Database(':memory:');
db.exec(`
  CREATE TABLE t3(x, y);
  INSERT INTO t3 VALUES ('a', 4),
                        ('b', 5),
                        ('c', 3),
                        ('d', 8),
                        ('e', 1);
`);

db.aggregate('sumint', {
  start: 0,
  step: (acc, value) => acc + value,
});

using query = db.prepare('SELECT sumint(y) as total FROM t3');
query.get(); // { total: 21 }

database.close()

<!-- YAML added: v22.5.0 -->

Closes the database connection. An exception is thrown if the database is not open. An [ERR_INVALID_STATE][] error is thrown if the method is called while a statement is executing, such as inside a user-defined function, an aggregate function, an authorizer callback, or a ['sqlite.db.query'][] subscriber. This method is a wrapper around [sqlite3_close_v2()][].

database.loadExtension(path[, entryPoint])

<!-- YAML added: - v23.5.0 - v22.13.0 -->

  • path {string} The path to the shared library to load.
  • entryPoint {string} The name of the extension's entry-point function. When omitted, SQLite derives the entry point from the shared library's filename; pass this argument explicitly when the derived name does not match.

Loads a shared library into the database connection. This method is a wrapper around [sqlite3_load_extension()][]. It is required to enable the allowExtension option when constructing the Database instance.

import { Database } from 'node:sqlite';
const database = new Database(':memory:', { allowExtension: true });

// Load using the entry point derived from the filename.
database.loadExtension('./decimal.dylib');

// Override the entry point when the derived name does not match.
database.loadExtension('./base64.dylib', 'sqlite3_base64_init');
const { Database } = require('node:sqlite');
const database = new Database(':memory:', { allowExtension: true });

// Load using the entry point derived from the filename.
database.loadExtension('./decimal.dylib');

// Override the entry point when the derived name does not match.
database.loadExtension('./base64.dylib', 'sqlite3_base64_init');

database.enableLoadExtension(allow)

<!-- YAML added: - v23.5.0 - v22.13.0 -->

  • allow {boolean} Whether to allow loading extensions.

Enables or disables the loadExtension SQL function, and the loadExtension() method. When allowExtension is false when constructing, you cannot enable loading extensions for security reasons.

database.enableDefensive(active)

<!-- YAML added: - v25.1.0 - v24.12.0 -->

  • active {boolean} Whether to set the defensive flag.

Enables or disables the defensive flag. When the defensive flag is active, language features that allow ordinary SQL to deliberately corrupt the database file are disabled. See [SQLITE_DBCONFIG_DEFENSIVE][] in the SQLite documentation for details.

database.location([dbName])

<!-- YAML added: - v24.0.0 - v22.16.0 -->

  • dbName {string} Name of the database. This can be 'main' (the default primary database) or any other database that has been added with [ATTACH DATABASE][] Default: 'main'.
  • Returns: {string | null} The location of the database file. When using an in-memory database, this method returns null.

This method is a wrapper around [sqlite3_db_filename()][]

database.exec(sql)

<!-- YAML added: v22.5.0 -->

  • sql {string} A SQL string to execute.

This method allows one or more SQL statements to be executed without returning any results. This method is useful when executing SQL statements read from a file. This method is a wrapper around [sqlite3_exec()][].

database.function(name[, options], fn)

<!-- YAML added: - v23.5.0 - v22.13.0 -->

  • name {string} The name of the SQLite function to create.
  • options {Object} Optional configuration settings for the function. The following properties are supported:
  • deterministic {boolean} If true, the [SQLITE_DETERMINISTIC][] flag is set on the created function. Default: false.
  • directOnly {boolean} If true, the [SQLITE_DIRECTONLY][] flag is set on the created function. Default: false.
  • useBigIntArguments {boolean} If true, integer arguments to function are converted to BigInts. If false, integer arguments are passed as JavaScript numbers. Default: false.
  • varargs {boolean} If true, function may be invoked with any number of arguments (between zero and [SQLITE_MAX_FUNCTION_ARG][]). If false, function must be invoked with exactly function.length arguments, which must be an integer. Default: false.
  • fn {Function} The JavaScript function to call when the SQLite function is invoked. The return value of this function should be a valid SQLite data type: see [Type conversion between JavaScript and SQLite][]. The result defaults to NULL if the return value is undefined.

This method is used to create SQLite user-defined functions. This method is a wrapper around [sqlite3_create_function_v2()][].

database.setAuthorizer(callback)

<!-- YAML added: v24.10.0 changes: - version: v26.8.0 pr-url: https://github.com/nodejs/node/pull/65156 description: Accessing the invoking database connection from the authorizer callback now throws. -->

  • callback {Function|null} The authorizer function to set, or null to clear the current authorizer.

Sets an authorizer callback that SQLite will invoke whenever it attempts to access data or modify the database schema through prepared statements. This can be used to implement security policies, audit access, or restrict certain operations. This method is a wrapper around [sqlite3_set_authorizer()][].

When invoked, the callback receives five arguments:

  • actionCode {number} The type of operation being performed (e.g., SQLITE_INSERT, SQLITE_UPDATE, SQLITE_SELECT).
  • arg1 {string|null} The first argument (context-dependent, often a table name).
  • arg2 {string|null} The second argument (context-dependent, often a column name).
  • dbName {string|null} The name of the database.
  • triggerOrView {string|null} The name of the trigger or view causing the access.

The callback must return one of the following constants:

  • SQLITE_OK - Allow the operation.
  • SQLITE_DENY - Deny the operation (causes an error).
  • SQLITE_IGNORE - Ignore the operation (silently skip).

SQLite requires that the authorizer callback not modify the database connection that invoked it, which includes preparing and stepping statements. Methods that would do so throw an error with code ERR_INVALID_STATE while the callback is on the stack, including database.prepare(), database.exec(), the execution methods of that connection's statements, iterators, and tag stores, and database.setAuthorizer() itself. Other connections remain usable.

The callback can also be invoked from within statement.run(), statement.get(), and similar methods, because SQLite may re-prepare a statement during execution after a schema change.

Separately, a statement that is currently being executed cannot be reentered. Calling statement.close() on it would free the virtual machine that is running, and re-running it through statement.run(), statement.get(), statement.all(), statement.iterate(), iterator.next(), iterator.return(), or the equivalent tag store methods would reset that virtual machine mid-execution. All of these throw an ERR_INVALID_STATE error instead. This applies to any callback SQLite invokes during execution, such as a user-defined function. Other statements on the connection remain usable.

Operations that touch no SQLite state stay available from the callback: sqlTagStore.clear(), which only drops cached statements, and next() and return() on an already-drained iterator, which keep returning { done: true }.

const { Database, constants } = require('node:sqlite');
const db = new Database(':memory:');

// Set up an authorizer that denies all table creation
db.setAuthorizer((actionCode) => {
  if (actionCode === constants.SQLITE_CREATE_TABLE) {
    return constants.SQLITE_DENY;
  }
  return constants.SQLITE_OK;
});

// This will work
using query = db.prepare('SELECT 1');
query.get();

// This will throw an error due to authorization denial
try {
  db.exec('CREATE TABLE blocked (id INTEGER)');
} catch (err) {
  console.log('Operation blocked:', err.message);
}
import { Database, constants } from 'node:sqlite';
const db = new Database(':memory:');

// Set up an authorizer that denies all table creation
db.setAuthorizer((actionCode) => {
  if (actionCode === constants.SQLITE_CREATE_TABLE) {
    return constants.SQLITE_DENY;
  }
  return constants.SQLITE_OK;
});

// This will work
using query = db.prepare('SELECT 1');
query.get();

// This will throw an error due to authorization denial
try {
  db.exec('CREATE TABLE blocked (id INTEGER)');
} catch (err) {
  console.log('Operation blocked:', err.message);
}

database.isOpen

<!-- YAML added: - v23.11.0 - v22.15.0 -->

  • Type: {boolean} Whether the database is currently open or not.

database.isTransaction

<!-- YAML added: - v24.0.0 - v22.16.0 -->

  • Type: {boolean} Whether the database is currently within a transaction. This method is a wrapper around [sqlite3_get_autocommit()][].

database.limits

<!-- YAML added: v25.8.0 -->

  • Type: {Object}

An object for getting and setting SQLite database limits at runtime. Each property corresponds to an SQLite limit and can be read or written.

const db = new Database(':memory:');

// Read current limit
console.log(db.limits.length);

// Set a new limit
db.limits.sqlLength = 100000;

// Reset a limit to its compile-time maximum
db.limits.sqlLength = Infinity;

Available properties: length, sqlLength, column, exprDepth, compoundSelect, vdbeOp, functionArg, attach, likePatternLength, variableNumber, triggerDepth.

Setting a property to Infinity resets the limit to its compile-time maximum value.

database.open()

<!-- YAML added: v22.5.0 -->

Opens the database specified in the path argument of the Database constructor. This method should only be used when the database is not opened via the constructor. An exception is thrown if the database is already open.

database.serialize([dbName])

<!-- YAML added: v26.1.0 -->

  • dbName {string} Name of the database to serialize. This can be 'main' (the default primary database) or any other database that has been added with [ATTACH DATABASE][]. Default: 'main'.
  • Returns: {Uint8Array} A binary representation of the database.

Serializes the database into a binary representation, returned as a Uint8Array. This is useful for saving, cloning, or transferring an in-memory database. This method is a wrapper around [sqlite3_serialize()][].

import { Database } from 'node:sqlite';

const db = new Database(':memory:');
db.exec('CREATE TABLE t(key INTEGER PRIMARY KEY, value TEXT)');
db.exec("INSERT INTO t VALUES (1, 'hello')");
const buffer = db.serialize();
console.log(buffer.length); // Prints the byte length of the database
const { Database } = require('node:sqlite');

const db = new Database(':memory:');
db.exec('CREATE TABLE t(key INTEGER PRIMARY KEY, value TEXT)');
db.exec("INSERT INTO t VALUES (1, 'hello')");
const buffer = db.serialize();
console.log(buffer.length); // Prints the byte length of the database

database.deserialize(buffer[, options])

<!-- YAML added: v26.1.0 -->

  • buffer {Uint8Array} A binary representation of a database, such as the output of [database.serialize()][].
  • options {Object} Optional configuration for the deserialization.
  • dbName {string} Name of the database to deserialize into. Default: 'main'.

Loads a serialized database into this connection, replacing the current database. The deserialized database is writable. Existing prepared statements are finalized before deserialization is attempted, even if the operation subsequently fails. An [ERR_INVALID_STATE][] error is thrown if the method is called while a database callback is on the stack, for example a user-defined function, an aggregate function, an authorizer, or a changeset filter or conflict handler. This method is a wrapper around [sqlite3_deserialize()][].

import { Database } from 'node:sqlite';

const original = new Database(':memory:');
original.exec('CREATE TABLE t(key INTEGER PRIMARY KEY, value TEXT)');
original.exec("INSERT INTO t VALUES (1, 'hello')");
const buffer = original.serialize();
original.close();

const clone = new Database(':memory:');
clone.deserialize(buffer);
using query = clone.prepare('SELECT value FROM t');
console.log(query.get());
// Prints: { value: 'hello' }
const { Database } = require('node:sqlite');

const original = new Database(':memory:');
original.exec('CREATE TABLE t(key INTEGER PRIMARY KEY, value TEXT)');
original.exec("INSERT INTO t VALUES (1, 'hello')");
const buffer = original.serialize();
original.close();

const clone = new Database(':memory:');
clone.deserialize(buffer);
using query = clone.prepare('SELECT value FROM t');
console.log(query.get());
// Prints: { value: 'hello' }

database.prepare(sql[, options])

<!-- YAML added: v22.5.0 changes: - version: v26.8.0 pr-url: https://github.com/nodejs/node/pull/62757 description: Add the persistent option. - version: v26.8.0 pr-url: https://github.com/nodejs/node/pull/65157 description: Throw ERR_INVALID_ARG_VALUE if sql contains no statements. -->

  • sql {string} A SQL string to compile to a prepared statement.
  • options {Object} Optional configuration for the prepared statement.
  • readBigInts {boolean} If true, integer fields are read as BigInts. Default: inherited from database options or false.
  • returnArrays {boolean} If true, results are returned as arrays. Default: inherited from database options or false.
  • allowBareNamedParameters {boolean} If true, allows binding named parameters without the prefix character. Default: inherited from database options or true.
  • allowUnknownNamedParameters {boolean} If true, unknown named parameters are ignored. Default: inherited from database options or false.
  • persistent {boolean} If true, hints to SQLite that this statement will be retained for a long time and likely reused many times. SQLite currently responds to this hint by avoiding lookaside memory. Corresponds to the [SQLITE_PREPARE_PERSISTENT][] flag. Default: false.
  • Returns: {Statement} The prepared statement.

Compiles a SQL statement into a [prepared statement][]. This method is a wrapper around [sqlite3_prepare_v3()][].

database.createTagStore([maxSize])

<!-- YAML added: v24.9.0 -->

  • maxSize {integer} The maximum number of prepared statements to cache. Default: 1000.
  • Returns: {SQLTagStore} A new SQL tag store for caching prepared statements.

Creates a new [SQLTagStore][], which is a Least Recently Used (LRU) cache for storing prepared statements. This allows for the efficient reuse of prepared statements by tagging them with a unique identifier.

When a tagged SQL literal is executed, the SQLTagStore checks if a prepared statement for the corresponding SQL query string already exists in the cache. If it does, the cached statement is used. If not, a new prepared statement is created, executed, and then stored in the cache for future use. This mechanism helps to avoid the overhead of repeatedly parsing and preparing the same SQL statements.

Tagged statements bind the placeholder values from the template literal as parameters to the underlying prepared statement. For example:

sqlTagStore.get`SELECT ${value}`;

is equivalent to:

using statement = db.prepare('SELECT ?');
statement.get(value);

However, in the first example, the tag store will cache the underlying prepared statement for future use.

Note: The ${value} syntax in tagged statements binds a parameter to the prepared statement. This differs from its behavior in untagged template literals, where it performs string interpolation.

``js // This a safe example of binding a parameter to a tagged statement. sqlTagStore.runINSERT INTO t1 (id) VALUES (${id})`;

// This is an unsafe example of an untagged template string. // id is interpolated into the query text as a string. // This can lead to SQL injection and data corruption. db.run(INSERT INTO t1 (id) VALUES (${id})); ```

The tag store will match a statement from the cache if the query strings (including the positions of any bound placeholders) are identical.

// The following statements will match in the cache:
sqlTagStore.get`SELECT * FROM t1 WHERE id = ${id} AND active = 1`;
sqlTagStore.get`SELECT * FROM t1 WHERE id = ${12345} AND active = 1`;

// The following statements will not match, as the query strings
// and bound placeholders differ:
sqlTagStore.get`SELECT * FROM t1 WHERE id = ${id} AND active = 1`;
sqlTagStore.get`SELECT * FROM t1 WHERE id = 12345 AND active = 1`;

// The following statements will not match, as matches are case-sensitive:
sqlTagStore.get`SELECT * FROM t1 WHERE id = ${id} AND active = 1`;
sqlTagStore.get`select * from t1 where id = ${id} and active = 1`;

The only way of binding parameters in tagged statements is with the ${value} syntax. Do not add parameter binding placeholders (? etc.) to the SQL query string itself.

import { Database } from 'node:sqlite';

const db = new Database(':memory:');
const sql = db.createTagStore();

db.exec('CREATE TABLE users (id INT, name TEXT)');

// Using the 'run' method to insert data.
// The tagged literal is used to identify the prepared statement.
sql.run`INSERT INTO users VALUES (1, 'Alice')`;
sql.run`INSERT INTO users VALUES (2, 'Bob')`;

// Using the 'get' method to retrieve a single row.
const name = 'Alice';
const user = sql.get`SELECT * FROM users WHERE name = ${name}`;
console.log(user); // { id: 1, name: 'Alice' }

// Using the 'all' method to retrieve all rows.
const allUsers = sql.all`SELECT * FROM users ORDER BY id`;
console.log(allUsers);
// [
//   { id: 1, name: 'Alice' },
//   { id: 2, name: 'Bob' }
// ]
const { Database } = require('node:sqlite');

const db = new Database(':memory:');
const sql = db.createTagStore();

db.exec('CREATE TABLE users (id INT, name TEXT)');

// Using the 'run' method to insert data.
// The tagged literal is used to identify the prepared statement.
sql.run`INSERT INTO users VALUES (1, 'Alice')`;
sql.run`INSERT INTO users VALUES (2, 'Bob')`;

// Using the 'get' method to retrieve a single row.
const name = 'Alice';
const user = sql.get`SELECT * FROM users WHERE name = ${name}`;
console.log(user); // { id: 1, name: 'Alice' }

// Using the 'all' method to retrieve all rows.
const allUsers = sql.all`SELECT * FROM users ORDER BY id`;
console.log(allUsers);
// [
//   { id: 1, name: 'Alice' },
//   { id: 2, name: 'Bob' }
// ]

database.createModule(name, options)

<!-- YAML added: v26.11.0 -->

  • name {string} The name of the virtual table module. This name is used in CREATE VIRTUAL TABLE ... USING name statements and as an eponymous table name.
  • options {Object} Module configuration settings.
  • columns {Array} An array of column definitions. Each element is an object with the following properties:
    • name {string} The name of the column.
    • type {string} The declared type of the column. Must be one of 'INTEGER', 'TEXT', 'REAL', 'BLOB', or 'ANY'.
    • hidden {boolean} If true, the column is hidden and acts as a parameter for table-valued function usage. Default: false.
  • rows {Function} A function called to produce rows when the virtual table is queried. The function receives values for hidden columns (parameters) as arguments, in the order they are defined. Must return an iterable (such as an array or generator) where each element is an array of column values.
  • directOnly {boolean} If true, the virtual table can only be used in top-level SQL statements and cannot be used inside triggers or views. Default: false.
  • useBigIntArguments {boolean} If true, integer parameters passed to rows are converted to BigInts. Default: false.

Registers a virtual table module with the database. This method is a wrapper around [sqlite3_create_module_v2()][]. Virtual tables allow JavaScript code to provide the backing data for SQL tables. The registered module can be used in two ways:

  • Eponymous table: Query the module name directly without creating a table (e.g., SELECT * FROM module_name).
  • Named virtual table: Use CREATE VIRTUAL TABLE t USING module_name to create a persistent virtual table.

Hidden columns can be used to pass parameters to the rows function using table-valued function syntax (e.g., SELECT * FROM module_name(param1, param2)).

Values yielded by rows follow the conversion rules in [Type conversion between JavaScript and SQLite][]: a {number} is stored as REAL and a {bigint} is stored as INTEGER, regardless of the column's declared type. Unlike an ordinary table, a virtual table does not apply column affinity to the values it returns, so yield a {bigint} when a column needs INTEGER storage:

db.createModule('counter', {
  columns: [{ name: 'value', type: 'INTEGER' }],
  *rows() {
    yield [1];   // typeof(value) is 'real'
    yield [2n];  // typeof(value) is 'integer'
  },
});
const { Database } = require('node:sqlite');

const db = new Database(':memory:');

db.createModule('generate_series', {
  columns: [
    { name: 'value', type: 'INTEGER' },
    { name: 'start', type: 'INTEGER', hidden: true },
    { name: 'stop', type: 'INTEGER', hidden: true },
    { name: 'step', type: 'INTEGER', hidden: true },
  ],
  *rows(start, stop, step) {
    start ??= 0;
    stop ??= 10;
    step ??= 1;
    for (let i = start; i <= stop; i += step) {
      yield [i];
    }
  },
});

console.log(db.prepare('SELECT * FROM generate_series(1, 5, 1)').all());
// Prints: [ { value: 1 }, { value: 2 }, { value: 3 }, { value: 4 }, { value: 5 } ]
import { Database } from 'node:sqlite';

const db = new Database(':memory:');

db.createModule('generate_series', {
  columns: [
    { name: 'value', type: 'INTEGER' },
    { name: 'start', type: 'INTEGER', hidden: true },
    { name: 'stop', type: 'INTEGER', hidden: true },
    { name: 'step', type: 'INTEGER', hidden: true },
  ],
  *rows(start, stop, step) {
    start ??= 0;
    stop ??= 10;
    step ??= 1;
    for (let i = start; i <= stop; i += step) {
      yield [i];
    }
  },
});

console.log(db.prepare('SELECT * FROM generate_series(1, 5, 1)').all());
// Prints: [ { value: 1 }, { value: 2 }, { value: 3 }, { value: 4 }, { value: 5 } ]

database.createSession([options])

<!-- YAML added: - v23.3.0 - v22.12.0 -->

  • options {Object} The configuration options for the session.
  • table {string} A specific table to track changes for. By default, changes to all tables are tracked.
  • db {string} Name of the database to track. This is useful when multiple databases have been added using [ATTACH DATABASE][]. Default: 'main'.
  • Returns: {Session} A session handle.

Creates and attaches a session to the database. This method is a wrapper around [sqlite3session_create()][] and [sqlite3session_attach()][].

database.applyChangeset(changeset[, options])

<!-- YAML added: - v23.3.0 - v22.12.0 -->

  • changeset {Uint8Array} A binary changeset or patchset.

  • options {Object} The configuration options for how the changes will be applied.

  • filter {Function} for each table affected by at least one change in the changeset, the filter callback is invoked with the table name as the first argument. If the return value is falsy, then no attempt is made to apply any changes to the table. Otherwise, if the return value is truthy or no filter callback is provided, all changes related to the table are attempted.
  • onConflict {Function} A function that determines how to handle conflicts. The function receives one argument, which can be one of the following values:

    • SQLITE_CHANGESET_DATA: A DELETE or UPDATE change does not contain the expected “before” values.
    • SQLITE_CHANGESET_NOTFOUND: A row matching the primary key of the DELETE or UPDATE change does not exist.
    • SQLITE_CHANGESET_CONFLICT: An INSERT change results in a duplicate primary key.
    • SQLITE_CHANGESET_FOREIGN_KEY: Applying a change would result in a foreign key violation.
    • SQLITE_CHANGESET_CONSTRAINT: Applying a change results in a UNIQUE, CHECK, or NOT NULL constraint violation.

    The function should return one of the following values:

    • SQLITE_CHANGESET_OMIT: Omit conflicting changes.
    • SQLITE_CHANGESET_REPLACE: Replace existing values with conflicting changes (only valid with SQLITE_CHANGESET_DATA or SQLITE_CHANGESET_CONFLICT conflicts).
    • SQLITE_CHANGESET_ABORT: Abort on conflict and roll back the database.

    When an error is thrown in the conflict handler or when any other value is returned from the handler, applying the changeset is aborted and the database is rolled back.

    Default: A function that returns SQLITE_CHANGESET_ABORT.

  • Returns: {boolean} Whether the changeset was applied successfully without being aborted.

An exception is thrown if the database is not open. This method is a wrapper around [sqlite3changeset_apply()][].

import { Database } from 'node:sqlite';

const sourceDb = new Database(':memory:');
const targetDb = new Database(':memory:');

sourceDb.exec('CREATE TABLE data(key INTEGER PRIMARY KEY, value TEXT)');
targetDb.exec('CREATE TABLE data(key INTEGER PRIMARY KEY, value TEXT)');

const session = sourceDb.createSession();

using insert = sourceDb.prepare('INSERT INTO data (key, value) VALUES (?, ?)');
insert.run(1, 'hello');
insert.run(2, 'world');

const changeset = session.changeset();
targetDb.applyChangeset(changeset);
// Now that the changeset has been applied, targetDb contains the same data as sourceDb.
const { Database } = require('node:sqlite');

const sourceDb = new Database(':memory:');
const targetDb = new Database(':memory:');

sourceDb.exec('CREATE TABLE data(key INTEGER PRIMARY KEY, value TEXT)');
targetDb.exec('CREATE TABLE data(key INTEGER PRIMARY KEY, value TEXT)');

const session = sourceDb.createSession();

using insert = sourceDb.prepare('INSERT INTO data (key, value) VALUES (?, ?)');
insert.run(1, 'hello');
insert.run(2, 'world');

const changeset = session.changeset();
targetDb.applyChangeset(changeset);
// Now that the changeset has been applied, targetDb contains the same data as sourceDb.

database[Symbol.dispose]()

<!-- YAML added: - v23.11.0 - v22.15.0 changes: - version: v24.2.0 pr-url: https://github.com/nodejs/node/pull/58467 description: No longer experimental. -->

Closes the database connection. If the database connection is already closed then this is a no-op.

Class: Session

<!-- YAML added: - v23.3.0 - v22.12.0 -->

session.changeset()

<!-- YAML added: - v23.3.0 - v22.12.0 -->

  • Returns: {Uint8Array} Binary changeset that can be applied to other databases.

Retrieves a changeset containing all changes since the changeset was created. Can be called multiple times. An exception is thrown if the database or the session is not open. This method is a wrapper around [sqlite3session_changeset()][].

session.patchset()

<!-- YAML added: - v23.3.0 - v22.12.0 -->

  • Returns: {Uint8Array} Binary patchset that can be applied to other databases.

Similar to the method above, but generates a more compact patchset. See [Changesets and Patchsets][] in the documentation of SQLite. An exception is thrown if the database or the session is not open. This method is a wrapper around [sqlite3session_patchset()][].

session.close()

Closes the session. An exception is thrown if the database or the session is not open, or if the session is currently generating a changeset or patchset. An [ERR_INVALID_STATE][] error is thrown if the method is called from a callback that SQLite invoked, such as an authorizer callback, a user-defined function, or a ['sqlite.db.query'][] subscriber, because SQLite may still be using the session. This method is a wrapper around [sqlite3session_delete()][].

session[Symbol.dispose]()

<!-- YAML added: v24.9.0 -->

Closes the session. If the session is already closed, then this is a no-op. An [ERR_INVALID_STATE][] error is thrown if the session is currently generating a changeset or patchset, or if the method is called from a callback that SQLite invoked, under the same conditions as [session.close()][].

Class: Statement

<!-- YAML added: v22.5.0 -->

This class represents a single [prepared statement][]. This class cannot be instantiated via its constructor. Instead, instances are created via the database.prepare() method. All APIs exposed by this class execute synchronously.

StatementSync is a deprecated alias for Statement, kept for backward compatibility with the class's previous name. See [DEP0211](https://nodejs.org/docs/latest/api/deprecations.md#dep0211-sqlitestatementsync.

A prepared statement is an efficient binary representation of the SQL used to create it. Prepared statements are parameterizable, and can be invoked multiple times with different bound values. Parameters also offer protection against [SQL injection][] attacks. For these reasons, prepared statements are preferred over hand-crafted SQL strings when handling user input.

Binding parameters

The all(), get(), iterate(), and run() methods bind their arguments to the parameters of the prepared statement before executing it. Parameters are either anonymous or named.

Anonymous parameters are written as ? in SQL and are bound in order from the arguments passed to the method. The ?NNN form assigns SQLite parameter index NNN to a placeholder. Avoid mixing numbered and named parameters because they share parameter indexes.

db.prepare('SELECT ? AS a, ? AS b').get('x', 42);
// { a: 'x', b: 42 }
db.prepare('SELECT ?2 AS a, ?1 AS b').get('first', 'second');
// { a: 'second', b: 'first' }

Named parameters begin with one of the prefix characters $, :, or @ in SQL. They are bound from an object passed as the first argument. Repeating a name in the SQL binds the same value to every occurrence.

db.prepare('SELECT $a AS a, $b AS b').get({ $a: 1, $b: 2 });
// { a: 1, b: 2 }
db.prepare('SELECT :a AS a').get({ ':a': 1 });
// { a: 1 }
db.prepare('SELECT @a AS a').get({ '@a': 1 });
// { a: 1 }
db.prepare('SELECT $k AS a, $k AS b').get({ k: 7 });
// { a: 7, b: 7 }

The last example omits the prefix character from the object key. Bare names are allowed by default; see [statement.setAllowBareNamedParameters()][] for their caveats.

Binding a key that does not name a parameter of the statement throws an ERR_INVALID_STATE error unless unknown named parameters are ignored. See [statement.setAllowUnknownNamedParameters()][].

Parameters that are never bound are NULL, and binding undefined has the same effect, so { $a: undefined } and {} are equivalent. Because undefined is not an object, passing it in place of namedParameters binds it as an anonymous parameter instead.

See [Type conversion between JavaScript and SQLite][] for the values that can be bound. Binding any other value throws an ERR_INVALID_ARG_TYPE error.

statement.all([namedParameters][, ...anonymousParameters])

<!-- YAML added: v22.5.0 changes: - version: v26.10.0 pr-url: https://github.com/nodejs/node/pull/65709 description: Bind undefined to NULL. - version: v26.8.0 pr-url: https://github.com/nodejs/node/pull/62001 description: Add support for boole

(本文超出站点单文档体积上限,已截断)