I built this to support upcoming backend deployments for schools in India on local, low-power "potato" hardware.
The problem: `better-sqlite3` is incredibly fast, but it’s synchronous. On low-power CPUs, a single 50ms query blocks the Node.js event loop for every other concurrent request. This is a massive bottleneck on the edge where you can't just throw more hardware at the problem.
I built better-sqlite3-pool to handle this. Since reliability is critical for my use case, I spent the time to port and verify the entire `better-sqlite3` test suite against this implementation.
Key Features:
- Non-blocking: Uses worker threads (with auto-scaling) to keep the main event loop free for I/O.
- Verified Correctness: 100% of the original better-sqlite3 tests pass.
- WAL-safe Encryption: Handles the atomic key broadcast required for SQLCipher + WAL mode.
- Zombie Transaction Reaper: Auto-rolls back transactions idle for >30s to prevent permanent SQLITE_BUSY locks.
I’m sharing this now because the logic is fully verified. It solves exactly the kind of event-loop contention that usually makes people think SQLite isn't viable for Node.js production—especially on hardware where you can't afford to waste a single CPU cycle.
dilipvamsi•2h ago
The problem: `better-sqlite3` is incredibly fast, but it’s synchronous. On low-power CPUs, a single 50ms query blocks the Node.js event loop for every other concurrent request. This is a massive bottleneck on the edge where you can't just throw more hardware at the problem.
I built better-sqlite3-pool to handle this. Since reliability is critical for my use case, I spent the time to port and verify the entire `better-sqlite3` test suite against this implementation.
Key Features: - Non-blocking: Uses worker threads (with auto-scaling) to keep the main event loop free for I/O. - Verified Correctness: 100% of the original better-sqlite3 tests pass. - WAL-safe Encryption: Handles the atomic key broadcast required for SQLCipher + WAL mode. - Zombie Transaction Reaper: Auto-rolls back transactions idle for >30s to prevent permanent SQLITE_BUSY locks.
I’m sharing this now because the logic is fully verified. It solves exactly the kind of event-loop contention that usually makes people think SQLite isn't viable for Node.js production—especially on hardware where you can't afford to waste a single CPU cycle.