A SQL query has a pipeline before it has an answer. This diagram walks the four machines inside a database: the parser, the rewriter, the optimizer, and the executor. The parser turns text into a tree; the rewriter normalizes it; the optimizer turns the logical tree into a physical plan by scoring alternatives against a cost model built from table statistics. Then the executor runs it.
The interesting design decision is the iterator model: every operator implements next(), and rows flow up the tree one at a time instead of materializing whole intermediate results. That's why a million-row join can run in bounded memory, and why the first row of a query can arrive before the query is finished. The ordering of stages matters because each one constrains the next: the parser can only feed the rewriter valid trees, the optimizer can only choose among plans the executor can run, and the executor's streaming behavior determines how the result is delivered.