DuckDB 2.0 LTS ships Quack client-server mode, async I/O and a first-class VARIANT type

The DuckDB team has released version 2.0.0, a long-term-support release codenamed Cinnamon Teal and described in the official announcement as the largest feature release in the project's history, built from close to 20,000 commits since version 1.5. Support runs until at least October 2027.

Three supported lines at once

The release leaves three DuckDB versions under maintenance. DuckDB 2.0 is the new LTS line. The previous LTS, 1.4, stays supported until late November 2026, and 1.5 — the most recent feature release — has been extended to March 2027, which the team says effectively turns it into an LTS release as well, leaving room for testing before the move. The CLI and Python clients are available immediately; Go, R and Java clients, along with some extensions, will follow over the coming days because they need extra changes and review. Since 2.0 is deliberately feature-heavy where 1.0 prioritised stability, the announcement also walks through breaking changes and migration steps.

DuckDB gains a client-server mode

DuckDB started life as an in-process engine, but version 1.5.3 introduced the Quack protocol and its quack extension, which let a DuckDB process act as a server for its databases. According to the announcement, 2.0 ships a polished version of that protocol with performance and stability work, plus a new CONNECT statement that attaches to a remote database and switches the session to it in a single command. CONNECT is not limited to Quack: it also targets PostgreSQL and MySQL, and a new remote pushdown optimizer sends queries to those servers instead of dragging whole tables across the wire. The CLI adds -serve and -connect arguments for quick client-server setups. On the security side, the server listens on localhost by default; exposing it directly via allow_other_hostname is intended for testing only, and the team recommends a TLS-terminating reverse proxy for real deployments.

Async I/O and a grown-up VARIANT

Version 2.0 introduces asynchronous I/O for reading Parquet and CSV files. The I/O layer now scales independently of query processing, keeping several reads in flight in the background, which the team says brings much more parallelism to remote reads and markedly faster queries on object storage such as s3:// paths.

The VARIANT type, first seen in 1.5, is now fully integrated. It stores schema-less, semi-structured data such as JSON while retaining columnar performance: DuckDB detects the common structure in your data and shreds it so it compresses well and executes fast. The pipeline works end to end, from shredded execution straight out of storage through shredded VARIANT reading and writing for Parquet, backed by a family of variant_* functions.

A parser built for agents and extensions

The 2.0 CLI detects when a coding agent such as Claude Code, Codex or Cursor is driving it and switches to agent mode: compact Markdown tables instead of padded boxes, explicit notices when results are truncated, early termination of runaway queries, errors reported as JSON, and expected-cost estimates before long queries so an agent can decide whether to wait. In the team's experiments on TPC-H, agent mode cut the amount of output a model had to read by 59 percent. Users can force it on with -agent or off with -no-agent.

Under the hood, DuckDB's own PEG-based SQL parser, which debuted as an opt-in feature in 1.5, becomes the default in place of the PostgreSQL-derived parser. Extensions can now hook into the grammar itself, opening the door to extensions that expose entirely new SQL syntax, and error messages gain precise source locations. The new parser is designed to behave like the old one. Triggers also ship in this release.

DuckDB on Android and iOS

A tutorial published on dev.to the same day explores a different angle: embedding DuckDB 2.0 as a mobile analytics engine. The author walks through a Kotlin setup on Android using the JDBC artifact and a Swift Package Manager setup on iOS, querying local Parquet files so aggregations run on-device without a network hop. The post reports benchmarks on a Pixel 7 against one million rows — a count-plus-group-by at roughly 90ms for DuckDB versus roughly 1,800ms for SQLite — though these are the author's figures rather than official ones. The practical advice includes setting memory_limit explicitly (the example uses 256MB) and providing a spill directory on mobile, keeping SQLite or Room for mutable app state because DuckDB favours append-only analytics, using prepared statements for file paths, and skipping DuckDB entirely below roughly 10,000 rows where SQLite is fast enough.

Why it matters

An LTS window stretching to late 2027 gives teams a dependable target for a database that increasingly turns up in unusual places: laptops, data pipelines, object-storage analytics and now phones. The Quack protocol and the remote pushdown optimizer stretch DuckDB beyond single-process use, VARIANT narrows the gap between JSON's flexibility and columnar speed, and agent mode is a candid acknowledgment that a growing share of SQL is now written and read by models rather than people. For embedded analytics in particular, a stable, supported release was the missing ingredient, and it has now arrived.