Definition
An embedded database runs as a library inside the application process rather than as a separate server reached over a network socket. The application links the database engine directly — SQLite as a C library, DuckDB as a similar in-process analytical engine, LevelDB and RocksDB as key-value engines — and reads, writes, and queries happen via function calls into that library. There is no separate process to start, no port to open, no authentication layer, and no network hop on the data path.
Embedded databases trade away the multi-client server architecture in exchange for radical operational simplicity. A single file on disk is the whole database. Backups are file copies. Deployment is shipping the application binary. The classic separation between application and database becomes a single deployable unit — useful in mobile apps, desktop software, edge devices, ETL jobs, test fixtures, and increasingly in analytical workloads where the data fits on one machine.
Why it matters
How it works
The embedded database is loaded as a shared library or statically linked into the application binary. The library exposes a familiar API — SQL via a connect() and execute(), or a key-value interface via get() and put() — and stores data in one or a few files on the local filesystem. Transactions, indexing, query planning, and crash recovery all run inside the application process, sharing its address space and lifecycle. When the application exits, the engine exits with it; when the application starts, opening the database file is a single function call.
The model's strengths and limits are mirror images of the client-server alternative. Strengths: trivial deployment, no network overhead, no per-connection cost, full SQL or full key-value semantics on local data, easy testability because a fresh database is a fresh temporary file. Limits: only one process can typically hold a write lock at a time (though SQLite's WAL mode allows concurrent readers with one writer), data lives on one machine so horizontal scaling means partitioning at the application layer, and the database's resources compete with the application's. The pragmatic guidance is well established — if the working set fits on one machine and the access pattern is dominated by a single application (or read replicas thereof), an embedded database removes an entire tier of infrastructure for no functional loss.