node:sqlite renamed DatabaseSync to Database

A class rename in a minor release is normally a red flag. This one is the opposite — it is the least disruptive way Node.js could have made room for something it has not shipped. But the detail that matters most to anyone already using node:sqlite is buried in a PR thread, not in the release notes.

Here is what actually changed, what did not, and why the word Sync disappearing is the most interesting part.

What shipped on 7 October

Node.js 26.11.0, released by Antoine du Hamel, lists the change in its Notable Changes as “sqlite: rename DatabaseSync and StatementSync”, flagged SEMVER-MINOR, from PR #65988 by Guilherme Araújo.

The current node:sqlite documentation now presents the module's classes as Database, Statement, Session and SQLTagStore. The canonical example in the docs reads:

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

The old names are documented as aliases. Verbatim from the docs: “DatabaseSync is a deprecated alias for Database, kept for backward compatibility with the class's previous name”, pointing at DEP0210, with the matching sentence for StatementSync pointing at DEP0211.

The same release also graduated process.ref and process.unref to stable, promoted Alpine Linux to tier 2, added Buffer.stringLength() and buffer.isLatin1, added http.isValidHeaderName() and isValidHeaderValue(), and added a --process-timeout=N flag. The sqlite rename is the only item in the list that touches a public class name.

The deprecation is doc-only, and that was argued for

This is the part worth reading the thread for. PR #65988's own description says the plan is to “Keep old names as aliases with doc-only deprecations.” That phrasing is not decoration — the PR discussion shows the alternative was live on the table.

The contributor had initially added a runtime deprecation for DatabaseSync and asked whether that was right, given that node:sqlite is not yet stable. Collaborator jasnell replied that the DatabaseSync deprecation “should also be a doc-only deprecation first.” RafaelGSS made the semver argument explicitly: because DatabaseSync is stable, a runtime deprecation would force a semver-major change. He signed off with “Existing usage continues to work without a runtime warning, so semver-minor makes sense to me.”

cjihrig asked the blunt version of the question — whether an alias is left behind at all, warning that without one “this will break every single current user.”

Practical translation: upgrade to 26.11.0 and your existing new DatabaseSync(...) code runs unchanged and silently. Node's deprecation policy defines a documentation-only deprecation as one “expressed only within the Node.js API docs” that generates “no side-effects while running Node.js”, with some such deprecations warning only under --pending-deprecation or NODE_PENDING_DEPRECATION=1. A runtime deprecation, by contrast, prints a process warning on first use and throws under --throw-deprecation.

So the practical upgrade risk here is close to zero. The planning risk is not.

Why the Sync suffix had to go

A rename that removes information from a name is usually a mistake. DatabaseSync told you something true and important: every method on it blocks the event loop. Database does not say that. The API is no less synchronous than it was last week.

The reason is visible in nodejs/node#57445, the stabilisation issue for the module. Trevor Burnham proposed renaming DatabaseSync to Database and putting the asynchronous API behind a separate node:sqlite/promises import path — the convention fs and stream already use. Under that design, the suffix is redundant: the import path carries the distinction, so node:sqlite exports a blocking Database and node:sqlite/promises would export a non-blocking one.

The alternative, raised by everett1992 in the same thread, was a separate DatabaseAsync class carrying only async methods. That would have kept DatabaseSync as the permanent name. Burnham's point was that the open async PR adds an async Database alongside DatabaseSync, which would effectively lock the Sync naming in place forever. Renaming first is what keeps the /promises option open.

That async PR — #62015, “sqlite: add batched async Database API” — is still open. It implements async counterparts using a strict FIFO operation queue that batches operations per connection before dispatching to the thread pool, trading latency for throughput. Its author lists exec(), statement preparation and get()/all()/run() with bound parameters as working, and location, loadExtension, enableLoadExtension and enableDefensive as outstanding. Review comments at the time of writing are about rebasing and commit sign-off, and one commenter asks whether the work is still ongoing.

So the sequence is: the rename landed in a stable release; the thing it was for has not landed at all.

The module is a release candidate, not stable

Worth saying plainly, because a lot of writing about node:sqlite treats it as done: the docs give it Stability: 1.2 — Release candidate, with the history noting that SQLite became a release candidate in v25.7.0. Release candidate means the shape is close to final and still allowed to move. A class rename arriving with doc-only aliases is exactly what that stability tier permits.

If you are choosing a SQLite layer for a Node service right now, that tier is the number to weigh, not the convenience of a built-in. The same judgement applies to any built-in-versus-package decision; our framework for comparing developer tools treats stability commitments as a first-class criterion rather than a footnote, and the database and storage category lists the alternatives that have been stable for years.

What to do in your codebase

Situation	Action
Existing DatabaseSync code	Nothing is required. It runs without a warning.
New code on 26.11.0+	Use Database and Statement.
Code that must also run on older Node	Keep DatabaseSync. The new names do not exist before 26.11.0.
Hand-written type declarations	Add the new names. Generate shapes from sample rows with a JSON to TypeScript converter.
Lint rules or codemods matching *Sync	Audit them. A blocking call no longer announces itself in the class name.

That last row is the one teams will actually get wrong. If your code review habit is “grep for Sync before merging anything on the request path”, that habit now has a hole in it. The SQL formatter and JSON formatter are useful for reading what those queries return, but no tool tells you a call blocks once the name stops saying so. Write it in the comment.

The pattern, not the incident

Node has been shipping quality-of-life changes into node: builtins at a pace that makes release notes worth reading line by line rather than skimming the headline feature. The type-stripping changes in Node 26 had the same property: the interesting detail was a removal, not an addition.

One more oddity from the same day. Node 26.11.1 shipped on 7 October 2026 too, and its notable changes are three reverts — the documentation redesign, a doc-kit verbosity toggle, and a tooling bump. The release page does not call it a regression fix or name an issue. If you pin Node by patch version in CI, 26.11.1 is a documentation-tooling rollback, not a runtime change.

FAQ

Does upgrading to Node 26.11.0 break code that uses DatabaseSync?

No. DatabaseSync and StatementSync remain as deprecated aliases for Database and Statement, and the deprecations are documentation-only, so no runtime warning is printed. PR #65988 states the intent as keeping the old names as aliases with doc-only deprecations.

Is Database asynchronous now?

No. It is the same synchronous class with a shorter name. An asynchronous API is proposed in PR #62015, which is still open and unmerged, and the discussion there points to a separate node:sqlite/promises import path as the expected home for it.

Which Node versions have the new names?

The rename landed in 26.11.0 on 7 October 2026. Code that also has to run on earlier releases should keep using DatabaseSync, or feature-detect, because Database is not exported by versions that predate the rename.

Is node:sqlite stable enough for production?

The docs mark it Stability 1.2, release candidate, having reached that tier in v25.7.0. That tier allows exactly this kind of change. Teams that cannot absorb API movement should weigh an established package instead, and treat the stability tier as a selection criterion rather than a detail.

What are DEP0210 and DEP0211?

They are the deprecation identifiers the node:sqlite documentation cites for the DatabaseSync and StatementSync aliases respectively. They are the entries to watch: a move from documentation-only to runtime would be the signal that the aliases are on a real removal path.

Why did Node 26.11.1 ship the same day as 26.11.0?

Its notable changes are three reverts covering the documentation redesign and doc tooling. The release page does not state a reason or reference an issue, and none of the three commits touches the runtime.

---

A rename that costs nothing today is still a rename worth understanding, because the reason for it tells you what is coming next.