DuckDB v2.0 is previewing, and the headline feature isn't a new type or a faster join. It's the thing the project spent a decade refusing to build: a server.
The quack extension implements DuckDB's native protocol for talking to other DuckDBs and graduates to stable in v2.0. Any DuckDB process can serve its databases over the network, and any other DuckDB can attach to it and route queries there with the new CONNECT statement. The in-process database that built its entire identity on "no server to install" now speaks to itself across the wire.
Read the rest of the list and it's the same theme: triggers, the VARIANT type for semi-structured data, asynchronous I/O, a new SQL parser, a new default storage format, a reworked C API. Over 10,000 commits since v1.5 shipped in March. The project calls v2.0 "Cyanoptera" and says it outright — "this release kicks off the year of DuckDB as a server."
Why this matters beyond the database crowd: the agent stack is quietly standardizing on DuckDB as the default embedded datastore. First-class client/server means the same engine running inside your agent's process can now be the shared backend for a fleet of them — without the Postgres migration every agent startup has on a roadmap. That story just got weaker.
The verdict: watch this one. 491 points and 85 comments on HN in hours. A founding design constraint, reversed by the people who built it.