DuckDB, two years into 1.x: the re-verdict

This journal reviewed DuckDB's case when the single-node argument was still contrarian. DuckDB 1.0 shipped in June 2024, the project's stability covenant with its users, and two years is enough runway to do the thing review publications rarely do: re-open the verdict and check it against events.

What we said, compressed: most analytical workloads fit on one machine, the machine got very large, and a fast embedded engine would eat the low end of the warehouse market from below. Worth adopting, for the workloads that fit.

What held up: the workload claim, entirely. The pattern we keep meeting in practice is the laptop-sized "big data" estate: the nightly pipeline distributing sixty gigabytes across a cluster whose coordination overhead exceeds the compute, replaced by one process and a Parquet directory. The 1.x line kept its compatibility promise, which sounds unremarkable until you audit how few data tools have ever kept one. Format stability, we note again, is a feature vendors underprice and users under-demand.

What we got less right: the framing of "versus the warehouse". The engine did not mainly replace warehouses. It replaced glue: the pandas stages, the ad hoc Spark jobs, the CSV-shuffling middle of pipelines whose endpoints stayed where they were. The warehouse kept the governed core; the single node took the workbench. That is a smaller revolution than the discourse promised and a larger one than the skeptics allowed, and it is the usual shape of these things.

The re-verdict: worth adopting stands, upgraded from "for workloads that fit" to "check whether yours fits before renewing anything that charges by the node". The check costs an afternoon: point the engine at your largest actual working set, on the biggest machine you can rent by the hour, and read the timings. Most readers will be surprised in the cheap direction.

Reviews that never re-open are press releases with patience. This one re-opens again in 2028.