Explain the execution flow of a query in DuckDB from SQL to result?

Running a SQL query in DuckDB passes through several distinct stages inside the same process, from raw SQL text to a materialized result, all without any network round-trip since everything happens in-process.

The parser turns SQL text into an abstract syntax tree, the binder resolves table and column references against the actual schema and performs type checking, and the optimizer applies a series of rewrites, pushing filters down as early as possible, reordering joins, choosing join algorithms, based on table statistics, to produce an efficient physical execution plan.

The vectorized executor then runs that plan, reading only the row groups and columns the plan actually needs (pruned using zone maps and column selection), processing data in batches through a pipeline of operators distributed across threads via morsel-driven parallelism, and finally returns the result back to the host application in whatever format was requested (a DuckDB result object, a Pandas DataFrame, an Arrow table, and so on).