WAL SQLiteEdge SQLite Archive
BP-05 // ZERO-IPC JS/TS

Bun:sqlite & Node.js better-sqlite3: Why Synchronous Beats Async Pools at 25k RPS

SQLiteEdge JS/TS concurrency blueprint: how synchronous better-sqlite3 and bun:sqlite avoid TCP N+1 round-trips using 4ms transaction micro-batching.

MODELED DESIGN TARGET
24,800 TPS
READ PATH / RPO TARGET
0.09 ms
REFERENCE NVME PROFILE
$24–$48 HF NVMe

JavaScript developers instinctively reach for async database drivers, yet async wrappers around SQLite (like node-sqlite3) serialize mutex queues across libuv threads and tank throughput. Both `better-sqlite3` on Node.js and native `bun:sqlite` execute synchronously inside the thread in ~8–25 microseconds, eliminating N+1 latency and hitting 25,000+ HTTP RPS when paired with micro-batched write queues.

In our SQLiteEdge BP-05 reference guide, every configuration rule below follows official SQLite 3.46 documentation and public vendor specifications retrieved 2026-11-12.

SQLiteEdge Architecture Rules for Bun:sqlite & Node.js better-sqlite3 Micro-Batching

  1. Use synchronous prepared statements (`const stmt = db.prepare(...)`) cached at module startup—never re-compile SQL strings inside request handlers.
  2. Coalesce high-frequency webhook or analytics writes across a 5ms event-loop tick into a single `db.transaction(batch)()` call to amortize one NVMe fsync across 100+ inserts.
  3. For multi-core read scaling on an 8-vCPU VPS, run 1 Primary Writer process/worker + N Read-Only HTTP workers (`new Database(path, { readonly: true })`) behind SO_REUSEPORT.
  4. Schedule `PRAGMA optimize;` every 4 hours on long-lived processes so SQLite refreshes query planner statistics (`sqlite_stat1`) without stalling traffic.

SQLiteEdge Reference Snippet: Micro-Batched Write Coalescer (Node better-sqlite3 / Bun)

Micro-Batched Write Coalescer (Node better-sqlite3 / Bun) 
import Database from 'better-sqlite3';

const db = new Database('/var/lib/app/saas.db');
db.pragma('journal_mode = WAL');
db.pragma('synchronous = NORMAL');
db.pragma('busy_timeout = 5000');
db.pragma('mmap_size = 8589934592');

const insertEvent = db.prepare(
  'INSERT INTO events (tenant_id, kind, payload, created_at) VALUES (?, ?, ?, ?)'
);
const commitBatch = db.transaction((rows) => {
  for (const r of rows) insertEvent.run(r.tenantId, r.kind, r.payload, r.ts);
});

// Coalesce bursty HTTP writes every 4ms -> 1 NVMe WAL flush = 40,000+ inserts/sec!
let queue = [];
setInterval(() => {
  if (queue.length === 0) return;
  const batch = queue;
  queue = [];
  commitBatch(batch);
}, 4);

SQLiteEdge Modeled Profile & Tariff Table (BP-05)

Public vendor prices retrieved 2026-11-12 (promotional and renewal rates may change at checkout); throughput figures reflect theoretical single-queue sizing models rather than unarchived lab claims.

JS Database Architecture12-Query Page Load LatencyMax Single-Node RPSCPU Overhead
Remote Cloud Postgres (1.4ms RTT x 12)18.6 ms3,400 RPSHigh TLS + Socket Serialization
Async node-sqlite3 (libuv threadpool)2.9 ms6,800 RPSMutex Queue Contention
Node.js 22 + better-sqlite3 (WAL + mmap)0.21 ms24,500 RPSMinimal Zero-Copy C++
Bun + bun:sqlite + SO_REUSEPORT Workers0.14 ms38,000+ RPSUltra-Lean Zig/JSC

SQLiteEdge Spec-Matched NVMe & S3 Targets for BP-05

Open this BP-05 workload preset inside the SQLiteEdge PRAGMA Studio →

SQLiteEdge Engineering FAQ for BP-05

  • Does synchronous better-sqlite3 block the Node.js event loop?

    A single indexed point lookup on mmap-backed local NVMe takes ~10 microseconds (0.01ms)—meaning Node can execute 100 queries in 1 millisecond without blocking HTTP I/O. Only heavy analytical scans (>10ms) should be delegated to a read-only Worker Thread.

  • Why does CPU clock speed (3.5GHz+) matter so much for bun:sqlite and better-sqlite3?

    Because SQLite runs right inside your JS V8/JSC thread with zero network wait time, query speed is pure single-core CPU IPC + memory bandwidth—making Vultr 3.7GHz+ High Frequency nodes blazingly fast.