Embedded databases

Databases that run in-process — linked as a library or compiled to WASM, no server, no socket, no separate lifecycle. The process is the database: zero deployment friction, zero network hop, and the data lives or dies with the embedding application. The embedded model is why “just use SQLite” ends most small-data arguments, and the recent wave (DuckDB, PGlite, Grafeo) extends it to analytics, Postgres semantics, and graphs.

The trade-off stack, honestly: no concurrent writers from other processes (single-writer is the near-universal constraint), the DB’s memory is your process’s memory, and HA/failover is your problem — server databases exist because they solve exactly these (High Availability is the server world’s answer). What you gain: zero-latency access from code, trivial distribution (a file or a binary), and no ops surface. For read-mostly, single-owner, or edge/embedded workloads the exchange is a rout.

The field (all captured)

• sqlite (OSS) (10.6k★ mirror, C, public domain) — the most deployed database in existence: OLTP-shaped, single file, ACID, cross-platform to absurdity (every phone, browser, and plane). The default answer for local structured storage; the baseline all others are measured against. WASM build ships in every browser (origin-trialed node:sqlite too).
• duckdb (OSS) (41.7k★, C++, MIT) — “the SQLite of analytics”: in-process OLAP — columnar execution, vectorized, parallel; reads Parquet/CSV directly; Wickham-grade integration with Python/R dataframes. The engine that made local analytical SQL a first-class thing (and the one Evidence builds on — Markdown Slideshows BI-as-code).
• chdb (OSS) (2.9k★, Python/Apache-2.0) — in-process OLAP powered by the real ClickHouse: the ClickHouse engine itself embedded as a library (import chdb → query Parquet/CSV/Arrow with full CH SQL), not a reimplementation. The columnar-speed lane where DuckDB and chDB now compete head-to-head — CH syntax and functions as the differentiator, plus a Wasm build (wasm.chdb.io) extending the family’s browser story. USER framing at capture: “It looks like SQLite but ClickHouse.”
• pglite (OSS) (16.1k★, TS/WASM) — Postgres as a library: full PG compiled to WASM, <3 MB gzipped, extensions loadable (pgvector, PostGIS), reactive live queries. Runs in browser/Node/Bun/Deno. The “Postgres everywhere” play — PG semantics where only SQLite-WASM fit before; the trade is WASM’s single-connection, single-threaded execution.
• Grafeo (clippings/grafeo-dev.md, see Graph databases) — the graph entry: Rust, embedded and server modes, vectorized+SIMD traversal, all six query languages. The newest and least proven of the four, but completes the pattern: every database category is getting its in-process edition.

The family portrait: SQLite = OLTP, DuckDB = OLAP, chDB = ClickHouse-native OLAP, PGlite = Postgres-compat, Grafeo = graph — five workloads, one deployment model (and the OLAP slot now has two contenders: DuckDB the clean-slate engine vs chDB the embedded incumbent — a rare case of the original engine arriving in-process late). DuckDB is also becoming an ETL substrate: duckle (OSS) builds a self-hosted 385-component ETL/ELT platform (visual pipelines or SQL, dbt, CDC, reverse ETL, lineage, MCP for agents — no vendor cloud, no per-row billing) directly on it. DuckDB’s own positioning line (“in-process analytical”) is the template the others copied.

The convergence story

The embedded wave is converging with three other trends: WASM everywhere (browser + edge runtimes made “ship the database with the app” literal — PGlite in a browser tab), dataframes ↔ SQL (DuckDB querying Parquet/polars/pandas directly dissolved the ETL step — see evidence (OSS)‘s BI-as-code lane), and local-first software (the client owns the data, sync is a feature not an architecture). Kinship: pglite (OSS) as the pattern-carrier, Graph databases for the graph branch, AI engineering agent-memory angle — an agent’s working memory is increasingly an embedded DB (SQLite/DuckDB as scratchpad, graphs as knowledge store).

Related: Graph databases · High Availability (what you give up) · Markdown Slideshows (Evidence/DuckDB in practice) · Performance engineering (zero network hop = the elimination ladder applied to latency)