TL;DR: Most Node.js projects that reach for an embedded database want one of four different things — relational storage, a document model, a fast key-value store, or local analytics. Picking well means naming which of those you need first. Below is a neutral map of the options and the trade-offs that decide between them.
What "embedded" actually buys you
An embedded database runs in your process. No daemon, no connection string, no network hop, no separate thing to deploy and monitor. That single property is why they show up in CLI tools, Electron apps, desktop software, test suites, edge functions, and devices that sometimes have no network.
The cost is symmetric: because the database lives inside one process, concurrent writes from multiple processes are the hard limit. Nearly every difference below follows from that.
The four categories
Relational
SQLite is the default answer, and it deserves to be. It is the most widely deployed database engine in existence, its file format is a recognised long-term archival format, and its test suite is famously exhaustive. In Node.js, better-sqlite3 exposes a synchronous API that is usually faster than async alternatives for local disk work, because there is no event-loop round trip per query. Node.js has also shipped a built-in node:sqlite module, which removes the native-build step for basic use.
libSQL is a SQLite fork that adds server and replica modes while keeping the file format. It is worth knowing about when you start embedded but suspect you will later want a remote copy of the same data.
PGlite packages PostgreSQL itself into WebAssembly so it can run in-process, including in a browser. The appeal is dialect fidelity: if production is Postgres, testing against real Postgres semantics locally removes a class of surprises that SQLite's dialect differences can hide.
Document
PouchDB implements the CouchDB replication protocol, which makes it the mature choice when sync between devices is the actual requirement rather than local storage alone. RxDB sits a layer up: a reactive document database with pluggable storage engines (SQLite and others underneath) and built-in replication, aimed at local-first apps where the UI should update when data changes.
Two older names still turn up in search results and deserve a caveat. NeDB and LokiJS were popular in-process document stores, but both have seen little maintenance activity for years. Treat anything unmaintained as a liability for a project you intend to keep running — not because the code stopped working, but because unpatched dependencies and unanswered issues accumulate.
Key-value
LMDB (via lmdb-js) is a memory-mapped key-value store with a reputation for very fast reads, since lookups can avoid copying data out of the mapped pages. LevelDB, through the classic-level package and the wider abstract-level ecosystem, is the other well-trodden option and has the advantage of a pluggable backend interface.
Reach for these when your access pattern genuinely is "give me the value at this key" and you do not want a query planner in the path.
Analytical
DuckDB is columnar and vectorised, built for aggregate queries over many rows rather than fetching single records. It reads Parquet and CSV directly, which makes it unusually good at the "I have some files and I want to run SQL over them" task. It is the wrong tool for transactional row-at-a-time writes, and the right one for local analysis.
The trade-offs that actually decide it
| If you need… | The deciding factor |
|---|---|
| Durability above all | SQLite's track record and test suite are unmatched here |
| Sync across devices | PouchDB or RxDB — replication is the feature, not storage |
| Production-dialect parity | PGlite, if production runs Postgres |
| Aggregations over local files | DuckDB, by a wide margin |
| Raw key lookup speed | LMDB or LevelDB |
| Multiple processes writing | None of the above — you want a server |
Two more considerations decide more real projects than benchmarks do:
Native builds. Anything with a compiled component can complicate Docker images, serverless bundles, and CI on mixed architectures. WASM-based options and Node's built-in SQLite sidestep this.
Backup story. A single-file database is trivial to copy, which is a genuine operational advantage. Confirm the copy semantics your engine expects while the database is open, rather than assuming a plain file copy is safe under load.
How this list was assembled
PainHunt aggregates developer complaints across platforms — for this topic, chiefly Dev.to, Mastodon, GitHub, Hacker News, and technical forums. Within the DevTools category, the largest in our dataset, the recurring embedded-database complaints cluster around three themes, and notably none of them is raw speed:
- Write concurrency discovered late. Locking behaviour under concurrent writes is the single most repeated complaint — reported as a bottleneck found in production rather than a documented limit understood upfront. This is why the "multiple processes writing" row above is the one that should decide your choice first.
- Dev/prod dialect mismatch. Running SQLite locally against PostgreSQL in production is repeatedly described as producing complicated test suites and data inconsistencies. This is the concrete argument for PGlite when production is Postgres — the complaint exists because the mismatch is real.
- The exit path. Migrating off an embedded database once an application outgrows single-server use is described as harder than expected. Worth weighing at selection time, not at the point of pain.
A fourth appears often enough to mention: developers report genuine difficulty simply choosing between a relational store with JSON columns, a document store, and Postgres JSONB for flexible-schema work — which is the gap this article exists to close.
The maintenance caveat in the Document section is stated plainly for a related reason. The most common regret in this category is not picking a slow database; it is picking an abandoned one.
Related reading
- The commercial opportunity behind embedded document databases in Node.js — the market-gap view of the same problem space
- Where to find SaaS ideas in 2026 — how we source signals like the ones above
- Browse the underlying evidence in the PainHunt dashboard, or test an idea against real complaints