DuckDB Internals

DuckDB is an in-process OLAP database that crunches billions of rows on a laptop. No server, no config, no dependencies — just embed it and query. These pages dissect the engineering that makes this possible: vectorized execution, push-based pipelines, adaptive radix trees, and a query optimizer that rivals production systems ten times its size.

Inspired by the DiDi curriculum from the University of Tübingen. All content is original.

DuckDB Architecture Overview

Key Numbers

Vector Size
2,048
Execution Model
Push-based
Index Type
ART (Radix)
Parallelism
Morsel-driven
Storage
Columnar

Why DuckDB Exists

The Gap
Before DuckDB, local analytical queries meant either: (a) load everything into pandas (slow, memory-hungry), (b) stand up a PostgreSQL/ClickHouse server (ops overhead), or (c) use SQLite (row-store, terrible for analytics). There was no embedded columnar engine.
The Insight
Modern laptops have 8-64 cores and 16-128GB RAM — enough to analyze datasets that previously required distributed clusters. What was missing was a database engine designed to exploit this hardware without the operational complexity of a server.
The Result
DuckDB combines 30 years of database research (vectorized execution from MonetDB, morsel parallelism from HyPer, ART from Tübingen) into a single embeddable library. pip install duckdb and you have a full analytical engine.
✦ Live

Vectorized Execution

Process 2048 values at once instead of row-by-row — how DuckDB's columnar engine exploits CPU caches, SIMD, and pipeline parallelism

✦ Live

Query Pipeline

Push-based execution with morsel-driven parallelism — how DuckDB builds and runs query plans without materializing intermediate results

✦ Live

ART Indexing

Adaptive Radix Trees — the cache-friendly, space-efficient index structure DuckDB uses instead of B-trees

✦ Live

Sorting Large Tables

External merge sort with columnar layouts — how DuckDB sorts datasets bigger than memory without falling off a performance cliff

✦ Live

Memory Management

Buffer manager, memory limits, and spill-to-disk — how an in-process database handles datasets larger than available RAM

✦ Live

Query Optimizer

Join ordering, filter pushdown, common subexpression elimination — the rewrite rules that make DuckDB queries fast

✦ Live

Storage Format

Row groups, column segments, min/max indexes, and Parquet integration — how DuckDB persists and scans data on disk

✦ Live

DuckDB vs SQLite

Column-store vs row-store, OLAP vs OLTP, embedded vs embedded — when to use which and why the architecture matters

DuckDB vs Other Databases

DuckDBPostgreSQLSQLiteClickHouse
DeploymentEmbedded (in-process)Client-serverEmbedded (in-process)Client-server / cluster
Storage layoutColumnarRow-based (heap)Row-based (B-tree)Columnar (MergeTree)
Best forLocal analytics, data scienceOLTP + moderate OLAPOLTP, mobile, configProduction OLAP at scale
Execution modelVectorized, push-basedVolcano (pull, row)Virtual machine (row)Vectorized, push-based
ParallelismMorsel-driven (auto)Parallel query (limited)Single-threadedMulti-threaded + distributed
ConcurrencySingle writer, multi readerFull MVCCWAL mode multi-readerAppend-oriented
Index typeART (Adaptive Radix Tree)B-tree, GIN, GiSTB-treeSparse (MergeTree primary)
DependenciesZeroServer + extensionsZeroServer + ZooKeeper/Keeper