I wanted to bring attention to the pull request opened yesterday proposing to mark the node-sqlite3 library as unmaintained. While it hasn't been merged yet, this means TypeORM's current SQLite dependency will no longer be maintained.

TryGhost/node-sqlite3#1844

The timing makes sense when you consider that Node.js v22.5.0 introduced a built-in sqlite module. The built-in module eliminates the need for native addon compilation and its associated toolchain requirements.

Migrating from node-sqlite3 to the built-in module would bring several advantages. The built-in module simplifies the dependency story—it's just there as part of Node.js itself. There's no need for prebuilt binaries, fallback compilation, or the tooling that supports that infrastructure. The module would be maintained by the Node.js core team alongside the rest of the runtime, ensuring better long-term support and security updates. It would also reduce the dependency tree, always a plus for maintenance and security.

Of course, there are some considerations to think through. The built-in module is currently marked as experimental and requires Node.js v22.5.0 or higher. This means we'd need to think carefully about backwards compatibility and potentially maintain a transition period where both drivers are supported.

I think it's worth starting the conversation about how TypeORM might approach a transition away from node-sqlite3 in general. The node-sqlite3 library has served the community well for years, and with built-in Node.js support now available, it seems like a good time to explore the options. I'm curious to hear thoughts from the maintainers and community on timing and implementation approach.