The in-process database now ships a client-server protocol, async object-storage I/O, and a CLI that reshapes its output for coding agents, so DuckDB can serve remote databases and cut agent token consumption without leaving its embedded roots.
The Quack protocol (introduced in 1.5.3) gets a polished client-server mode with a new CONNECT statement; CONNECT also targets Postgres and MySQL, where a remote pushdown optimizer ships queries to the server instead of pulling tables over the wire. Server defaults to localhost; allow_other_hostname is testing-only, with TLS reverse proxy recommended for remote access.
Async I/O for Parquet, CSV, and native storage decouples the I/O layer from query processing, issuing background reads and keeping multiple requests in flight for faster S3/remote reads. The VARIANT type (from 1.5) now 'shreds' common structure for columnar compression and Parquet read/write via variant_* functions.
CLI agent mode auto-detects when run by Claude Code, Codex, or Cursor: compact Markdown tables, explicit truncation notices, early stops on runaway queries, JSON errors, and pre-run cost estimates. Self-reported TPC-H experiments cut DuckDB output the model had to read by 59%; toggle with -agent / -no-agent.
Full summary
DuckDB 2.0.0 LTS ("Cinnamon Teal") is a feature release built from roughly 20,000 commits since 1.5, supported until at least October 2027. It ships a polished Quack client-server protocol with a new CONNECT statement (also targeting Postgres and MySQL with remote query pushdown), asynchronous I/O for Parquet/CSV/native storage that decouples reads from query processing for faster object-storage access, and a fully integrated VARIANT type that shreds semi-structured data for columnar compression. A new CLI agent mode detects coding agents (Claude Code, Codex, Cursor) and emits compact Markdown, truncation notices, query cost estimates, and JSON errors, which the team reports cut DuckDB output the model reads by 59% on TPC-H. The PEG-based parser becomes default (replacing the 2018 YACC/Bison LALR(1) grammar), and the release adds triggers, a C API v2, self-hosted signed extension repositories, and SQL dialect extensions like NEAREST joins. Breaking changes include files written by 2.0 being unreadable by older versions, a C++17 requirement, a switch to Clang, removal of the ICU library in favor of a native 45 kB implementation, and deprecation of single-arrow lambda syntax; the team recommends shadow testing and, for critical workloads, waiting for the November patch. Performance and agent-mode figures are vendor self-reported without full methodology.
If PlanetScale's self-run numbers hold, Postgres full-text search can handle 25x the query throughput of ParadeDB on BM25 top-10 workloads without bolting on Elasticsearch, so a single Postgres instance becomes a viable search backend for apps that already live there.
Details
The architectural bet: TIN uses Postgres ctids (48-bit physical tuple locations: 32-bit page, 16-bit offset) as document identifiers instead of sequential per-segment IDs. This maps to two-level bitmaps (256-bit page-level fits an AVX2 register; offset-level fits one AVX-512 or two AVX2 registers), so conjunction/disjunction become vector AND/OR and counts use POPCNT.
No renumbering on merge: because a ctid means the same thing in every segment, merging segments can transfer bitmap ownership on disk rather than recompress and rewrite, cutting the write amplification that segment-based engines (ParadeDB, pg_textsearch) pay. Visibility checks are moved into TIN via custom scans that intersect against Postgres' page-level visibility map.
Vendor benchmark setup: single AWS i7i.8xlarge (local NVMe, AVX-512), Postgres 18.6 in a container capped at 8 vCPU / 32GB; shared_buffers=24GB, maintenance_work_mem=24GB, max_parallel_workers=8; ParadeDB Benchmarker (forked to pre-warm). Primary corpus was 85GB / 150M-doc Stack Exchange with a synthetic query trace (2-15 term substrings read as conjunction, disjunction, phrase = 1,719 queries).
PlanetScale announced TIN ("Text INdex"), a GA full-text search extension for its Postgres and Neki databases, exposed via CREATE INDEX ... USING tin(col) and a ==> match operator with BM25 scoring through tin.score(ctid). Its central design choice is using Postgres ctids (physical tuple locations) directly as document identifiers rather than sequential per-segment IDs, encoding postings as two-level page/offset bitmaps sized to AVX2/AVX-512 registers so conjunction, disjunction, and counting map to vector AND/OR and POPCNT instructions. The ctid approach also avoids the renumbering and write amplification that segment-merging engines incur, lets TIN read tuples in heap order, and lets it intersect against Postgres' page-level visibility map for MVCC-correct results. PlanetScale's own benchmarks, run on a single AWS i7i.8xlarge against an 85GB/150M-doc Stack Exchange corpus (plus Wikipedia, Reddit, and a 797GB mixed set), report TIN beating ParadeDB v0.25.2 by roughly 8x to 57x on QPS across read-only and concurrent-write workloads while reading far less data per query. Of the compared engines (ParadeDB, pg_textsearch v1.4.0, built-in GIN), only ParadeDB completed every benchmark; GIN exhausted memory on disjunction queries and pg_textsearch supports only disjunction and stalled writes under read load. All performance figures are vendor self-reported, though the article documents the container limits, tuned Postgres parameters, and forked ParadeDB Benchmarker used.