- Author
- Kyle Cheung, Co-founder and CEO, Greybeam
- Published
- 4 May 2026
- Kind
- Company blog post, first of a three-part explainer
- Original
- www.greybeam.ai/blog/duckdb-internals-part-1
- Subject
- Databases and storage
- Themes
- Close to the machine, Getting good
What it is
Kyle Cheung explains why DuckDB is fast, following a query from SQL to storage. Execution is left to later parts.
What it says
- The post says DuckDB runs inside the host program, which avoids network serialization costs.
- It cites a 2017 paper finding client protocols often slowest.
- DuckDB runs a sequence of small optimizer passes that users can inspect and disable.
- Join key bounds from one side let the other scan skip row groups.
- Plans split into pipelines at operators like ORDER BY that need all input.
- Each thread keeps its own local state in a sink, then results are merged.
- Data is stored by column in row groups of up to 122,880 rows. Zone maps let scans skip them.
What evidence it gives
The post explains by description, small code and plan examples, and references to papers. It gives no timing tests of its own. It states that the optimization phase usually finishes in about a millisecond.
Interests and limits
The author runs Greybeam, which uses DuckDB and sells a multi-engine router. The post does not compare DuckDB against other engines. Execution is deferred to later parts.