better-sqlite3, sequelize, sqlite, and sqlite3 are all npm packages that provide access to SQLite databases from Node.js, but they serve very different use cases and architectural needs. better-sqlite3 and sqlite3 are low-level drivers that expose direct SQLite functionality with minimal abstraction—better-sqlite3 uses synchronous APIs for performance, while sqlite3 relies on callbacks and promises. sequelize is a full-featured ORM (Object-Relational Mapper) that supports multiple SQL databases including SQLite, offering high-level abstractions like models, associations, and migrations. The sqlite package is a lightweight wrapper around sqlite3 that simplifies basic usage but adds little beyond convenience methods. These tools range from raw database access to full data modeling layers, and the right choice depends heavily on your application’s complexity, performance requirements, and team expertise.
SQLite in Node.js: better-sqlite3 vs sequelize vs sqlite vs sqlite3
When you need a lightweight, file-based database in a Node.js application — whether for local development, desktop apps, or embedded systems — SQLite is often the go-to choice. But picking the right npm package to interact with it isn’t straightforward. The four main options (better-sqlite3, sequelize, sqlite, and sqlite3) differ dramatically in philosophy, performance, and abstraction level. Let’s cut through the noise and compare them as a seasoned engineer would.
🧱 Core Architecture: Raw Driver vs ORM vs Wrapper
better-sqlite3 is a synchronous, high-performance SQLite driver built on native bindings. It blocks the event loop during queries but delivers exceptional speed by avoiding async overhead.
// better-sqlite3: sync API
const db = require('better-sqlite3')('data.db');
const user = db.prepare('SELECT * FROM users WHERE id = ?').get(1);
sqlite3 is the classic async SQLite driver using libuv threads. Queries run off the main thread and return via callbacks or promises.
// sqlite3: async API
const sqlite3 = require('sqlite3').verbose();
const db = new sqlite3.Database('data.db');
db.get('SELECT * FROM users WHERE id = ?', [1], (err, row) => {
console.log(row);
});
sqlite is a thin async wrapper around sqlite3 that adds promise support and a cleaner interface, but no new capabilities.
// sqlite: simplified async
const sqlite = require('sqlite');
(async () => {
const db = await sqlite.open('data.db');
const user = await db.get('SELECT * FROM users WHERE id = ?', [1]);
})();
sequelize is a full ORM that supports SQLite (alongside PostgreSQL, MySQL, etc.). It abstracts SQL entirely behind model classes and query builders.
// sequelize: ORM layer
const { Sequelize, DataTypes } = require('sequelize');
const sequelize = new Sequelize({ dialect: 'sqlite', storage: 'data.db' });
const User = sequelize.define('User', {
name: DataTypes.STRING
});
const user = await User.findByPk(1);
⚡ Performance Characteristics
Performance varies drastically based on how each package handles I/O:
-
better-sqlite3is the fastest by design. Because it runs synchronously, there’s no context switching or thread pool overhead. This makes it perfect for CPU-bound or latency-sensitive tasks — but dangerous in high-concurrency web servers where blocking hurts throughput. -
sqlite3andsqliteare slower because every query spawns a background thread via libuv. This keeps the event loop free but adds measurable latency per query. For most CLI or desktop apps, this trade-off is acceptable. -
sequelizeadds the most overhead. Every query goes through model validation, association resolution, and SQL generation. While convenient, this can make simple operations 2–5x slower than raw drivers.
💡 Rule of thumb: If your app does < 100 queries/sec and values developer ergonomics,
sequelizeorsqlite3is fine. If you’re doing bulk inserts or tight loops (e.g., data migration),better-sqlite3will outperform others by orders of magnitude.
🔌 Installation and Native Dependencies
All four packages rely on native C++ addons, but their build processes differ:
-
better-sqlite3uses prebuilt binaries vianode-gyp-build. Installation is usually fast unless you’re on an unsupported platform. -
sqlite3compiles from source by default usingnode-gyp, which requires Python and a C++ compiler. This can fail in minimal Docker containers or CI environments without build tools. -
sqliteinheritssqlite3’s installation quirks since it depends on it. -
sequelizeitself is pure JavaScript, but when paired with SQLite, you still need to installsqlite3(orbetter-sqlite3via dialect options). So native compilation is unavoidable for SQLite usage.
🗃️ Schema Management and Migrations
How you evolve your database schema over time is critical:
better-sqlite3andsqlite3offer no built-in migration tools. You write rawALTER TABLEstatements or manage versions manually.
// Manual migration with better-sqlite3
db.exec(`
CREATE TABLE IF NOT EXISTS users_v2 (
id INTEGER PRIMARY KEY,
name TEXT,
email TEXT
);
`);
-
sqlitealso provides zero migration support — it’s just a query runner. -
sequelizeincludes a robust migration system via the CLI. You define up/down functions in JavaScript files, and Sequelize tracks which migrations ran.
// Sequelize migration
module.exports = {
up: async (queryInterface, Sequelize) => {
await queryInterface.addColumn('Users', 'email', Sequelize.STRING);
},
down: async (queryInterface) => {
await queryInterface.removeColumn('Users', 'email');
}
};
If your project requires frequent schema changes or team collaboration, Sequelize’s migration tooling is a major advantage.
🔄 Transaction Handling
All packages support transactions, but the APIs vary:
better-sqlite3 uses explicit transaction wrappers:
const insert = db.prepare('INSERT INTO logs (msg) VALUES (?)');
const insertMany = db.transaction((msgs) => {
for (const msg of msgs) insert.run(msg);
});
insertMany(['a', 'b', 'c']);
sqlite3 uses manual BEGIN/COMMIT or the serialize mode:
db.serialize(() => {
db.run('BEGIN');
db.run('INSERT INTO logs (msg) VALUES (?)', ['a']);
db.run('COMMIT');
});
sqlite mirrors sqlite3 but with promises:
await db.run('BEGIN');
await db.run('INSERT INTO logs (msg) VALUES (?)', ['a']);
await db.run('COMMIT');
sequelize provides a clean transaction helper:
const t = await sequelize.transaction();
try {
await User.create({ name: 'Alice' }, { transaction: t });
await t.commit();
} catch (err) {
await t.rollback();
}
Sequelize’s approach is the most developer-friendly, especially for nested operations.
📦 When to Avoid Each Package
-
Avoid
better-sqlite3in traditional web servers (Express, Koa) handling many concurrent requests. Its sync nature will block the event loop and degrade overall throughput. -
Avoid
sqlite3if you can’t tolerate native compilation issues or need the absolute best performance for batch operations. -
Avoid
sqlitein production. It offers no real benefit over usingsqlite3directly and adds an unnecessary dependency layer. -
Avoid
sequelizefor simple scripts, CLIs, or when you’re certain you’ll never switch databases. The abstraction tax isn’t worth it for trivial use cases.
🛠️ Real-World Decision Matrix
| Use Case | Recommended Package | Why |
|---|---|---|
| Electron desktop app | better-sqlite3 | Single-threaded, needs speed, no concurrency concerns |
| Express API with simple caching | sqlite3 | Async I/O fits web server model; stable and proven |
| Rapid prototype or tutorial | sqlite | Easy async syntax for learning (but upgrade later) |
| Enterprise app with complex models | sequelize | Migrations, relations, validations, and future DB flexibility |
| Data processing CLI tool | better-sqlite3 | Max throughput for ETL-like workloads |
| Mobile backend with SQLite-only | sequelize | Developer productivity outweighs minor perf loss |
✅ Final Guidance
There’s no universal “best” — only the right tool for your context:
- Need raw speed and control? →
better-sqlite3 - Building a standard Node.js service? →
sqlite3 - Want ORM convenience and scalability? →
sequelize - Just tinkering? →
sqlite(but don’t ship it)
Remember: SQLite itself is rock-solid. Your choice of driver or ORM should align with your team’s skills, performance budget, and long-term maintenance strategy — not hype or download counts.
- better-sqlite3:
Choose
better-sqlite3if you need maximum performance from SQLite in a single-threaded Node.js environment and are comfortable writing raw SQL. It’s ideal for CLI tools, local data caching, embedded applications, or any scenario where you control the schema and don’t need an ORM. Avoid it if you require async I/O without blocking the event loop or plan to scale across multiple processes. - sequelize:
Choose
sequelizeif you’re building a medium-to-large application that may eventually migrate to PostgreSQL, MySQL, or another SQL database, and you want features like model definitions, relationships, validations, and migrations. It’s well-suited for teams that prefer working with JavaScript objects over raw SQL and need cross-database portability. Be aware of the performance overhead compared to raw drivers. - sqlite3:
Choose
sqlite3if you need a stable, widely used SQLite driver that supports asynchronous operations via callbacks or promises and integrates well with existing callback-based codebases. It’s a safe default for general-purpose SQLite access in Node.js when you don’t need the speed ofbetter-sqlite3or the abstractions of an ORM. Note that it requires native compilation during install. - sqlite:
Choose
sqliteonly for simple prototypes or educational projects where you want a slightly friendlier API thansqlite3without adopting a full ORM. It wrapssqlite3with async/await syntax but doesn’t add significant functionality. In production systems, prefer eithersqlite3directly or a more capable layer likebetter-sqlite3orsequelize.
better-sqlite3 
The fastest and simplest library for SQLite in Node.js.
- Full transaction support
- High performance, efficiency, and safety
- Easy-to-use synchronous API (better concurrency than an asynchronous API... yes, you read that correctly)
- Support for user-defined functions, aggregates, virtual tables, and extensions
- 64-bit integers (invisible until you need them)
- Worker thread support (for large/slow queries)
Help this project stay strong! 💪
better-sqlite3 is used by thousands of developers and engineers on a daily basis. Long nights and weekends were spent keeping this project strong and dependable, with no ask for compensation or funding, until now. If your company uses better-sqlite3, ask your manager to consider supporting the project:
How other libraries compare
select 1 row get() | select 100 rows all() | select 100 rows iterate() 1-by-1 | insert 1 row run() | insert 100 rows in a transaction | |
|---|---|---|---|---|---|
| better-sqlite3 | 1x | 1x | 1x | 1x | 1x |
| sqlite and sqlite3 | 11.7x slower | 2.9x slower | 24.4x slower | 2.8x slower | 15.6x slower |
You can verify these results by running the benchmark yourself.
Installation
npm install better-sqlite3
Requires Node.js v14.21.1 or later. Prebuilt binaries are available for LTS versions. If you have trouble installing, check the troubleshooting guide.
Usage
const db = require('better-sqlite3')('foobar.db', options);
const row = db.prepare('SELECT * FROM users WHERE id = ?').get(userId);
console.log(row.firstName, row.lastName, row.email);
Though not required, it is generally important to set the WAL pragma for performance reasons.
db.pragma('journal_mode = WAL');
In ES6 module notation:
import Database from 'better-sqlite3';
const db = new Database('foobar.db', options);
db.pragma('journal_mode = WAL');
Why should I use this instead of node-sqlite3?
node-sqlite3uses asynchronous APIs for tasks that are either CPU-bound or serialized. That's not only bad design, but it wastes tons of resources. It also causes mutex thrashing which has devastating effects on performance.node-sqlite3exposes low-level (C language) memory management functions.better-sqlite3does it the JavaScript way, allowing the garbage collector to worry about memory management.better-sqlite3is simpler to use, and it provides nice utilities for some operations that are very difficult or impossible innode-sqlite3.better-sqlite3is much faster thannode-sqlite3in most cases, and just as fast in all other cases.
When is this library not appropriate?
In most cases, if you're attempting something that cannot be reasonably accomplished with better-sqlite3, it probably cannot be reasonably accomplished with SQLite in general. For example, if you're executing queries that take one second to complete, and you expect to have many concurrent users executing those queries, no amount of asynchronicity will save you from SQLite's serialized nature. Fortunately, SQLite is very very fast. With proper indexing, we've been able to achieve upward of 2000 queries per second with 5-way-joins in a 60 GB database, where each query was handling 5–50 kilobytes of real data.
If you have a performance problem, the most likely causes are inefficient queries, improper indexing, or a lack of WAL mode—not better-sqlite3 itself. However, there are some cases where better-sqlite3 could be inappropriate:
- If you expect a high volume of concurrent reads each returning many megabytes of data (i.e., videos)
- If you expect a high volume of concurrent writes (i.e., a social media site)
- If your database's size is near the terabyte range
For these situations, you should probably use a full-fledged RDBMS such as PostgreSQL.
Upgrading
Upgrading your better-sqlite3 dependency can potentially introduce breaking changes, either in the better-sqlite3 API (if you upgrade to a new major version), or between your existing database(s) and the underlying version of SQLite. Before upgrading, review:
Documentation
- API documentation
- Performance (also see benchmark results)
- 64-bit integer support
- Worker thread support
- Unsafe mode (advanced)
- SQLite compilation (advanced)
- Contribution rules
- Code of conduct