· via dev.to (home feed)
DuckDB 2.0.0 LTS arrives with async I/O, VARIANT type and the Quack protocol
DuckDB 2.0.0 LTS, codenamed Cinnamon Teal, is the project's biggest feature release, adding async I/O, a native VARIANT type, triggers and the Quack client-server protocol. Files it writes cannot be opened by older versions.
The biggest feature release in DuckDB's history
DuckDB, the open-source analytical database that runs inside a single process, has shipped version 2.0.0 LTS. According to a Netics write-up on dev.to, the release — codenamed Cinnamon Teal and published on 21 October 2026 — was built from close to 20,000 commits since DuckDB 1.5, and the project describes it as its biggest feature release so far, a contrast with the stability-focused 1.0 line.
The LTS label comes with dates attached. DuckDB's release calendar, cited by Netics, lists 22 October 2027 as the end of life for 2.0.0. The calendar states that starting with version 1.4.0, every other release is a long-term support edition, with the community support period running about a year after release.
What ships in 2.0
The headline features:
- The Quack protocol, which lets DuckDB run in a traditional client-server setup rather than only embedded. It first appeared in DuckDB 1.5.3 in May, and 2.0 ships a polished version.
- Asynchronous I/O covering Parquet files, CSV files and DuckDB's native storage. The I/O layer scales independently from query processing and keeps multiple requests in flight, which the project says brings far more parallelism to remote reads and faster queries on object storage such as S3.
- A first-class VARIANT type, giving semi-structured data a native representation.
- Agent mode, where the CLI detects that a coding agent is driving it and switches to compact output.
- Triggers, via CREATE TRIGGER with BEFORE and AFTER variants at row or statement level. The announcement lists BEFORE … FOR EACH ROW and UPDATE … FOR EACH ROW as not yet supported, so trigger logic ported from another database needs case-by-case review.
- The extensible PEG-based SQL parser, optional since DuckDB 1.5, is now the default.
Internals changed as well. Clang is now the default compiler for release builds — the engine and core extensions on Linux and macOS, and the CLI on Windows — while most Windows core extensions remain on MSVC. The bundled ICU library has been dropped entirely: the icu extension now implements timezones, calendars and collations itself, with IANA timezone data compressed to around 45 kB.
A one-way storage format
The breaking change is in the file format. DuckDB versions before 2.0 cannot read database files created by 2.0, while 2.0 still reads and writes files created by earlier versions — and those older files remain readable by older releases. The practical trap sits in new files: once a service creates a database file under 2.0, it can no longer be opened by the version that service would roll back to.
The project's advice follows from that. Test 2.0.0 on a shadow system before switching production over, and if a workload is mission-critical, consider waiting for the first patch release in November. Netics adds that exporting Parquet or CSV copies of important tables before upgrading turns an irreversible step into a reversible one, since those formats sit outside the DuckDB file format that changed in 2.0.
Three support lines, then two
Until 17 November 2026, three DuckDB versions are supported in parallel: 1.4, whose community support ends that day; 1.5, extended to March 2027 in a move the announcement says effectively turns a non-LTS release into an LTS one; and 2.0 itself. After mid-November, two lines remain until March 2027. The next patch, 2.0.1, carries a tentative date of 18 November 2026.
Netics reads 1.5 as the conservative bridge: a team can sit on it until March 2027, run 2.0 on a shadow system in the meantime, and move across once a patch release or two has shipped. The announcement names the storage format as the most likely source of problems.
A migration checklist
Netics' suggested plan for a small data team fits on one page: export the data that matters to Parquet before touching anything; pin the client library version in each service so nothing creates 2.0 database files ahead of the shadow test; run 2.0.0 against a shadow copy and compare row counts and query results on the reports people actually read; then decide on a date and write down which version line the team stays on until then. A migration guide accompanies the release.
Why it matters
DuckDB is linked into Python services, CLI scripts, scheduled jobs and notebooks, and each of those upgrades on its own schedule. With the storage format now moving in one direction, a single upgraded service can strand a database file for everything still running 1.x, which makes the order of upgrades a planning decision in its own right. The LTS calendar turns DuckDB maintenance from an open-ended promise into a dated commitment, and the asynchronous I/O work targets the pattern where the engine is increasingly used: querying Parquet directly on object storage.
- #duckdb
- #database
- #release-notes
- #open-source
- #sql