{"id":23409,"date":"2026-08-17T00:00:00","date_gmt":"2026-08-17T00:00:00","guid":{"rendered":"https:\/\/scannn.com\/a-preview-of-duckdb-v2-0-duckdb\/"},"modified":"2026-08-17T00:00:00","modified_gmt":"2026-08-17T00:00:00","slug":"a-preview-of-duckdb-v2-0-duckdb","status":"publish","type":"post","link":"https:\/\/scannn.com\/lv\/a-preview-of-duckdb-v2-0-duckdb\/","title":{"rendered":"A Preview of DuckDB v2.0 \u2013 DuckDB"},"content":{"rendered":"\n
\n
\n
\n\t\t\t\t\t\t\t\t\t\t\tMark Raasveldt and Hannes M\u00fchleisen<\/span><\/p>\n

\n\t\t\t\t\t\t\t\t\t\t\t\t\t2026-08-17<\/span><\/p>\n

\t\t\t\t\t\t\t\t\t\t\t\t\t\t|<\/span>
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t16 min<\/span><\/p>\n<\/p><\/div>\n<\/p><\/div>\n

\n

TL;DR: DuckDB v2.0 is coming this fall. In this post, we preview its headline features: DuckDB as a server, triggers, the VARIANT type, asynchronous I\/O, a new SQL parser, a new storage format, and much more.<\/em><\/p>\n<\/p><\/div>\n

DuckDB v2.0 will be named \u201cCyanoptera\u201d after the cinnamon teal<\/a> (Anas cyanoptera),<\/em> a strikingly reddish-brown duck found in the western Americas.<\/p>\n

A major version bump is not something we do lightly, and it is not just ceremony: v2.0 ships a new SQL parser, a new default storage format, a reworked C API, and a small number of carefully chosen breaking changes. But above all, it is a feature release, built from over 10,000 commits since we released v1.5 in March. Where last year was the year of the lakehouse, this release kicks off the year of DuckDB as a server. We previewed many of these features in the \u201cState of the Duck\u201d talk at DuckCon #7<\/a>, if you prefer to watch instead of read.<\/p>\n

DuckDB is moving rather quickly, and we can only cover a small fraction of the changes here. Condensing all new features down to a shortlist is always a fight over what gets in, and yes, we know that what follows is technically a listicle (Ten Things Coming to DuckDB v2.0, Number Eight Will Shock You).<\/em> We are not proud of the format, but it works, so here it is, starting with the SQL-level features and working down into the engine.<\/p>\n

DuckDB has been an in-process database since day one. But people have asked us \u2013 very persistently \u2013 for a client\/server mode, and we have finally caved. The quack<\/code> extension<\/a> implements DuckDB’s native protocol for talking to other DuckDBs. It was released as a preview<\/a> shortly before DuckCon #7, graduates to stable in v2.0, and it is a big part of where DuckDB is headed: any DuckDB process can serve its databases over the network, and any other DuckDB can attach to it and route queries there using the new CONNECT<\/code> statement. For example:<\/p>\n

<\/p>\n

\n

quack:<\/p>\n

\n

\n

<\/svg> DuckDB client<\/svg><\/a><\/p>\n<\/h4>\n

\n
\n
ATTACH<\/span> 'quack:server.example.com'<\/span>\n    AS<\/span> qk<\/span> (<\/span>TOKEN<\/span> 'my_token'<\/span>);<\/span>\n\nCONNECT<\/span> qk<\/span>;<\/span>\nSELECT<\/span> count<\/span>(<\/span>*<\/span>)<\/span> FROM<\/span> events<\/span>;<\/span>\n-- executes on the server,<\/span>\n-- results stream back<\/span>\nDISCONNECT<\/span>;<\/span>\n<\/code><\/pre>\n<\/div><\/div>\n<\/p><\/div>\n<\/div>\n
<\/p>\n
\n
\n
CONNECT<\/span> 'postgres:\/\/localhost\/mydb'<\/span>;<\/span>\nSELECT<\/span> count<\/span>(<\/span>*<\/span>)<\/span> FROM<\/span> orders<\/span>;<\/span> -- runs on the PostgreSQL server<\/span>\nDISCONNECT<\/span>;<\/span>\n<\/code><\/pre>\n<\/div>\n<\/div>\n
If you have worked with analytical systems in the past, you may assume that DuckDB cannot handle transactional workloads. But DuckDB has been built as a transactional, multi-connection database with full MVCC and transaction isolation since day one. Most users just never needed that in a single-user scenario. It turns out DuckDB handles transactions well: it’s fast enough to compete with general-purpose databases like PostgreSQL on quite a few workloads, and the client\/server pattern finally lets that machinery shine in multi-tenant, long-running deployments.<\/p>\n
The VARIANT<\/code> type shipped in DuckDB v1.5<\/a>, and the way to think about it is JSON on steroids. Basically, imagine if JSON were fast. Like JSON, a VARIANT<\/code> column can store differently-shaped data in every row. Unlike JSON, it is not a text format: DuckDB automatically detects the common structure hidden in your semi-structured data and \u201cshreds\u201d it, so it compresses well in storage and executes fast in queries, all without you ever declaring a schema. This makes VARIANT<\/code> a natural fit for real-time log ingestion, where streams of JSON-ish records share structure but evolve over time.<\/p>\n
In v2.0, this pipeline works end to end: shredded execution straight from storage (#20912<\/a>), extraction pushdown into scans (#22478<\/a>), shredded VARIANT<\/code> reading and<\/em> writing for Parquet, and a family of variant_*<\/code> functions:<\/p>\n
\n
\n
CREATE<\/span> TABLE<\/span> events<\/span> (<\/span>payload<\/span> VARIANT<\/span>);<\/span>\nINSERT<\/span> INTO<\/span> events<\/span>\nVALUES<\/span> (<\/span>'{\"user\": {\"id\": 42, \"tags\": [\"a\", \"b\"]}}'<\/span>::<\/span>JSON<\/span>::<\/span>VARIANT<\/span>);<\/span>\n\nSELECT<\/span> variant_type<\/span>(<\/span>payload<\/span>),<\/span> variant_keys<\/span>(<\/span>payload<\/span>)<\/span>\nFROM<\/span> events<\/span>;<\/span>\n\nSELECT<\/span> *<\/span>\nFROM<\/span> events<\/span>\nWHERE<\/span> variant_contains<\/span>(<\/span>payload<\/span>,<\/span> {<\/span>'user'<\/span>:<\/span> {<\/span>'id'<\/span>:<\/span> 42<\/span>}}::<\/span>VARIANT<\/span>);<\/span>\n<\/code><\/pre>\n<\/div>\n<\/div>\n
Longer term, likely soon after v2.0 (but don’t hold us to it), we plan to back the regular JSON<\/code> type with VARIANT<\/code>, so existing JSON workloads get all of these benefits without changing a single query.<\/p>\n
Triggers have been a long-standing feature request, and DuckDB v2.0 delivers them in full: BEFORE<\/code> and AFTER<\/code> triggers, FOR EACH ROW<\/code> and FOR EACH STATEMENT<\/code>, transition tables via REFERENCING OLD\/NEW TABLE<\/code>, multiple triggers per event, RETURNING<\/code> on triggered tables, and DROP TRIGGER<\/code>.<\/p>\n
The classic use case is audit tables: something happens in the system, and a trigger records what changed. For example:<\/p>\n
\n
\n
CREATE<\/span> TABLE<\/span> target<\/span> (<\/span>id<\/span> INTEGER<\/span>,<\/span> val<\/span> INTEGER<\/span>);<\/span>\nCREATE<\/span> TABLE<\/span> audit<\/span> (<\/span>id<\/span> INTEGER<\/span>,<\/span> old_val<\/span> INTEGER<\/span>,<\/span> new_val<\/span> INTEGER<\/span>);<\/span>\n\nCREATE<\/span> TRIGGER<\/span> trg_audit<\/span> AFTER<\/span> UPDATE<\/span> ON<\/span> target<\/span>\nREFERENCING<\/span> OLD<\/span> TABLE<\/span> AS<\/span> o<\/span> NEW<\/span> TABLE<\/span> AS<\/span> n<\/span>\nFOR<\/span> EACH<\/span> STATEMENT<\/span>\n    INSERT<\/span> INTO<\/span> audit<\/span>\n    SELECT<\/span> n.id<\/span>,<\/span> o.val<\/span>,<\/span> n.val<\/span>\n    FROM<\/span> o<\/span>\n    JOIN<\/span> n<\/span> ON<\/span> o.id<\/span> =<\/span> n.id<\/span>;<\/span>\n\nINSERT<\/span> INTO<\/span> target<\/span> VALUES<\/span> (<\/span>1<\/span>,<\/span> 10<\/span>),<\/span> (<\/span>2<\/span>,<\/span> 20<\/span>);<\/span>\nUPDATE<\/span> target<\/span> SET<\/span> val<\/span> =<\/span> val<\/span> *<\/span> 10<\/span> WHERE<\/span> id<\/span> <=<\/span> 2<\/span>;<\/span>\nSELECT<\/span> *<\/span> FROM<\/span> audit<\/span>;<\/span>\n<\/code><\/pre>\n<\/div>\n<\/div>\n\n\n\n\n\n\n
id<\/th>\nold_val<\/th>\nnew_val<\/th>\n<\/tr>\n<\/thead>\n
1<\/td>\n10<\/td>\n100<\/td>\n<\/tr>\n
2<\/td>\n20<\/td>\n200<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Triggers fit naturally with long-running DuckDB services, and we are also planning to use them internally to build several upcoming features. They are fully exposed at the SQL level too, so you can build your own cool stuff with them.<\/p>\n
As always, DuckDB’s SQL dialect keeps growing. A few favorites from this release cycle:<\/p>\n
With NEAREST<\/code> joins<\/strong> (#24137<\/a>), top-k similarity search becomes a join clause, handy for vector and embedding workloads:<\/p>\n
\n
\n
SELECT<\/span> q.user_id<\/span>,<\/span> t.product_id<\/span>\nFROM<\/span> users<\/span> q<\/span>\n    INNER<\/span> JOIN<\/span> products<\/span> t<\/span> APPROX<\/span> NEAREST<\/span> 2<\/span>\n    BY<\/span> SIMILARITY<\/span> array_cosine_similarity<\/span>(<\/span>q.embedding<\/span>,<\/span> t.embedding<\/span>);<\/span>\n<\/code><\/pre>\n<\/div>\n<\/div>\n
\n
\n
WITH<\/span> moved<\/span> AS<\/span> MATERIALIZED<\/span> (<\/span>\n    DELETE<\/span> FROM<\/span> staging<\/span> RETURNING<\/span> *<\/span>\n)<\/span>\nINSERT<\/span> INTO<\/span> archive<\/span> SELECT<\/span> *<\/span> FROM<\/span> moved<\/span>;<\/span>\n<\/code><\/pre>\n<\/div>\n<\/div>\n
\n
\n
CREATE<\/span> SCHEMA<\/span> finance<\/span>;<\/span>\nCREATE<\/span> SCHEMA<\/span> finance.reports<\/span>;<\/span>\nCREATE<\/span> TABLE<\/span> finance.reports.q3<\/span> (<\/span>revenue<\/span> DECIMAL<\/span>);<\/span>\n<\/code><\/pre>\n<\/div>\n<\/div>\n
\n
\n
SET<\/span> VARIABLE<\/span> threshold<\/span> =<\/span> 100<\/span>;<\/span>\nSELECT<\/span> *<\/span> FROM<\/span> orders<\/span> WHERE<\/span> amount<\/span> ><\/span> $<\/span>threshold<\/span>;<\/span>\n<\/code><\/pre>\n<\/div>\n<\/div>\n
\n
\n
SELECT<\/span> json_set<\/span>(<\/span>'{\"a\":1}'<\/span>,<\/span> '$.b'<\/span>,<\/span> '2'<\/span>);<\/span>\n<\/code><\/pre>\n<\/div>\n<\/div>\n\n\n\n\n\n
json_set(‘{“a”:1}’, ‘$.b’, ‘2’)<\/th>\n<\/tr>\n<\/thead>\n
{“a”:1,”b”:2}<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
And recursive CTEs with USING KEY<\/code><\/a> aggregation<\/strong> (#19481<\/a>) enable iterative algorithms in pure SQL, backed by the rewritten recursive CTE engine described below:<\/p>\n
\n
\n
WITH<\/span> RECURSIVE<\/span> tbl<\/span>(<\/span>a<\/span>,<\/span> b<\/span>)<\/span> USING<\/span> KEY<\/span> (<\/span>a<\/span>,<\/span> avg<\/span>(<\/span>b<\/span>))<\/span> AS<\/span> (<\/span>\n    SELECT<\/span> 1<\/span>,<\/span> 5<\/span>\n    UNION<\/span>\n    SELECT<\/span> a<\/span>,<\/span> b<\/span> -<\/span> 1<\/span> FROM<\/span> tbl<\/span> WHERE<\/span> b<\/span> ><\/span> 0<\/span>\n)<\/span>\nTABLE<\/span> tbl<\/span>;<\/span>\n<\/code><\/pre>\n<\/div>\n<\/div>\n
Interacting with object stores like S3 is central to the DuckDB experience: your data has to come from somewhere, and it often sits in object storage. DuckDB has long been able to read from object stores in parallel, but synchronous access placed a limit on how fast this could go. DuckDB v2.0 introduces asynchronous I\/O throughout the engine. We described the design in detail in a dedicated blog post<\/a>.<\/p>\n
Thanks to asynchronous access, the I\/O layer now scales independently from the query processing layer, which means far more parallelism for remote reads and dramatically faster queries on network storage. Parquet support came first (#23662<\/a>), with CSV (#23961<\/a>) and DuckDB’s own file format (#24654<\/a>) following, along with asynchronous Parquet writes (#23283<\/a>) and new MMAP<\/code> and DIRECT_IO<\/code> modes (#22988<\/a>). Local storage benefits a little too, but network storage is where you will see the big gains.<\/p>\n
As with every release, a lot of work went into making your existing queries faster without you doing anything. To pick some highlights: partial aggregates are now pushed below joins (#22572<\/a>) and redundant aggregations are reused (#24543<\/a>), the recursive CTE engine has been rewritten (#22211<\/a>), aggregations now spill to disk when they outgrow memory (#24499<\/a>), and the Windows CLI got approximately 2.2\u00d7 faster at multi-threaded result materialization (#24036<\/a>).<\/p>\n
How much faster can this get? Here is a microbenchmark you can run on a laptop: single-source reachability over a graph with one million edges, written as a plain recursive CTE<\/a>.<\/p>\n
\n
\n
CREATE<\/span> TABLE<\/span> edges<\/span> AS<\/span>\n    SELECT<\/span> (<\/span>range<\/span> %<\/span> 100_000<\/span>)::<\/span>INTEGER<\/span> AS<\/span> src<\/span>,<\/span>\n           ((<\/span>range<\/span> *<\/span> 13<\/span> +<\/span> 7<\/span>)<\/span> %<\/span> 100_000<\/span>)::<\/span>INTEGER<\/span> AS<\/span> dst<\/span>\n    FROM<\/span> range<\/span>(<\/span>1_000_000<\/span>);<\/span>\n\nWITH<\/span> RECURSIVE<\/span> reachable<\/span>(<\/span>node<\/span>)<\/span> AS<\/span> (<\/span>\n    SELECT<\/span> 0<\/span>\n    UNION<\/span>\n    SELECT<\/span> dst<\/span> FROM<\/span> edges<\/span>,<\/span> reachable<\/span> WHERE<\/span> src<\/span> =<\/span> node<\/span>\n)<\/span>\nSELECT<\/span> count<\/span>(<\/span>*<\/span>)<\/span> FROM<\/span> reachable<\/span>;<\/span>\n<\/code><\/pre>\n<\/div>\n<\/div>\n\n\n\n\n\n\n
Version<\/th>\nRun time<\/th>\n<\/tr>\n<\/thead>\n
DuckDB v1.5.4<\/td>\n4.90 s<\/td>\n<\/tr>\n
DuckDB v2.0 (preview)<\/td>\n0.12 s<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
As you can see, DuckDB v2.0 is about 40\u00d7 faster (!) for the same recursive query.<\/p>\n
Row-group pruning has been massively expanded: min-max indexes (zone maps)<\/a> and Parquet Bloom filters<\/a> now skip data for structs, lists, decimals, UUIDs, IN<\/code> filters, and even function predicates:<\/p>\n
\n
\n
-- these now prune row groups instead of scanning them:<\/span>\nSELECT<\/span> *<\/span> FROM<\/span> logs<\/span> WHERE<\/span> contains<\/span>(<\/span>message<\/span>,<\/span> 'ERROR'<\/span>);<\/span>\nSELECT<\/span> *<\/span> FROM<\/span> t<\/span> WHERE<\/span> substr<\/span>(<\/span>code<\/span>,<\/span> 1<\/span>,<\/span> 3<\/span>)<\/span> =<\/span> 'NL-'<\/span>;<\/span>\nSELECT<\/span> *<\/span> FROM<\/span> 'data\/*.parquet'<\/span> WHERE<\/span> id<\/span> IN<\/span> (<\/span>1<\/span>,<\/span> 5<\/span>,<\/span> 9<\/span>);<\/span>\n<\/code><\/pre>\n<\/div>\n<\/div>\n
DuckDB v2.0 bumps the default storage format version<\/a> to v2.0.0 (#22875<\/a>).<\/p>\n
Column metadata is now loaded lazily (#22333<\/a>), so wide tables open faster too. The DICT_FSST<\/code> string compression method is enabled by default (#23733<\/a>), deletes are stored compactly (#24336<\/a>), and the storage layer performs much stronger corruption validation on read. In short: databases with big indexes and wide tables open faster and use far less memory. The new storage format also allows checkpoint vacuuming to compact tables with ART indexes by incrementally remapping entries whose row IDs change, avoiding a full index rebuild (#23653<\/a>).<\/p>\n
Later this year, ART indexes will be buffer-managed (#21458<\/a>, #23605<\/a>). This will allow ART index buffers to be evicted under memory pressure, and remove the restriction on the ART index fitting completely within memory.<\/p>\n
DuckDB has famously always used a parser derived from PostgreSQL’s. We have decided that enough is enough: v2.0 ships our own modern, extensible PEG-based parser (#22194<\/a>), an idea we first explored in our 2024 post on runtime-extensible parsers<\/a>. This change ties into the extension ecosystem: extensions can now hook into the grammar itself, so expect extensions that expose entirely new SQL syntax. It also brings better error messages with precise source locations.<\/p>\n
You should not actually notice anything from the parser swap as we designed it to be compatible with the old one. If you do notice, please file an issue.<\/p>\n
Timezone-aware timestamps, calendars, and collations in DuckDB have always been powered by the ICU library. ICU is a fine library, but we only ever used a small slice of it, while still carrying it around in every DuckDB distribution. In v2.0, the ICU library is gone entirely: the icu<\/code> extension now implements timezones, calendars, and collations itself (#24463<\/a>, #24403<\/a>), with the timezone data built directly from the IANA database and compressed down to around 45 kB. Everything keeps working exactly as before:<\/p>\n
\n
\n
SELECT<\/span> '2026-08-14 12:00:00'<\/span>::<\/span>TIMESTAMPTZ<\/span> AT<\/span> TIME<\/span> ZONE<\/span> 'Europe\/Paris'<\/span>;<\/span>\nSELECT<\/span> *<\/span> FROM<\/span> names<\/span> ORDER<\/span> BY<\/span> name<\/span> COLLATE<\/span> de<\/span>;<\/span>\n<\/code><\/pre>\n<\/div>\n<\/div>\n
Besides being much smaller and easier to keep up to date, the new implementation is also simply faster. Here’s a quick microbenchmark on a MacBook that converts 25 million timestamps to a timezone and filters 5 million strings with a German collation:<\/p>\n\n\n\n\n\n\n
Query<\/th>\nv1.5.4 (ICU)<\/th>\nv2.0 (native)<\/th>\nSpeedup<\/th>\n<\/tr>\n<\/thead>\n
ts AT TIME ZONE 'Europe\/Paris'<\/code>, 25 M rows<\/td>\n0.24 s<\/td>\n0.11 s<\/td>\n2.2\u00d7<\/td>\n<\/tr>\n
Filter with COLLATE de<\/code>, 5 M rows<\/td>\n0.15 s<\/td>\n0.06 s<\/td>\n2.6\u00d7<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Extensions are one of the best things about DuckDB, but today, most of them, including our own, build against the unstable C++ API<\/a>. Extension authors are required to rebuild and publish their extensions for every DuckDB release, even if the extension itself does not change. This is often a non-trivial operation for the extension author and a non-trivial coordination effort for the DuckDB team. Not rebuilding an extension means it can’t be installed on the latest version of DuckDB.<\/p>\n
DuckDB v2.0 will ship with a revamped C API (see #24702<\/a> for part 1). The API will have a versioned specification expressed in YAML<\/a> that uses an also versioned specification schema<\/em>, and tooling for code generation (#24135<\/a>). The schema lets us tag every symbol with its lifecycle and stability guarantees (#24435<\/a>). A large part of the API will be marked stable and frozen, providing a stable ABI across DuckDB versions.<\/p>\n
The API itself improves over the pre-2.0 C API in a number of ways. It provides coherent error handling and a unified set of conventions around naming and ownership. It covers a much larger feature surface, including scalar, aggregate, table, cast, and copy functions with named parameters and varargs, parsing and inspecting SQL statements, prepared statements, replacement scans, custom filesystems, direct access to vector buffers, values and types, and more. It supports streaming query result consumption. With this API we want to provide the primitives to access DuckDB’s most powerful features.<\/p>\n
You won’t need to program against the C API directly, though. We also provide a C++ API on top of it. It is a thin layer that compiles into your extension and talks only to the stable C ABI, so the binary you ship stays independent of DuckDB versions. It gives you a convenient, typed, well-documented way to access DuckDB’s API. We’re also working on bindings that provide the same for extension writers using Rust.<\/p>\n
So what will an extension using the C++ API look like? Here is a complete example, though the details may still change: a single file that registers a vectorized scalar function.<\/p>\n
\n
\n
#include<\/span> \"duckdb_cpp.hpp\"<\/span>\n<\/span>\nusing<\/span> namespace<\/span> duckdb_api<\/span>;<\/span>\n\nDUCKDB_CPP_EXTENSION_ENTRYPOINT<\/span>(<\/span>extension<\/span>)<\/span> {<\/span>\n    \/\/ add_numbers(a BIGINT, b BIGINT DEFAULT 2): adds two BIGINTs, one vector at a time<\/span>\n    ScalarFunction<\/span> function<\/span>;<\/span>\n    function<\/span>.<\/span>SetName<\/span>(<\/span>\"add_numbers\"<\/span>)<\/span>\n        .<\/span>SetSignature<\/span>(<\/span>FunctionSignature<\/span>::<\/span>Create<\/span>()<\/span>\n                        .<\/span>AddParameter<\/span>(<\/span>\"a\"<\/span>,<\/span> LogicalType<\/span>::<\/span>BIGINT<\/span>())<\/span>\n                        .<\/span>AddParameterDefault<\/span>(<\/span>\"b\"<\/span>,<\/span> LogicalType<\/span>::<\/span>BIGINT<\/span>(),<\/span> Value<\/span>::<\/span>Bigint<\/span>(<\/span>2<\/span>))<\/span>\n                        .<\/span>SetReturnType<\/span>(<\/span>LogicalType<\/span>::<\/span>BIGINT<\/span>()))<\/span>\n        .<\/span>SetExecCallback<\/span>([](<\/span>ScalarFunction<\/span>::<\/span>ExecInput<\/span> &<\/span>input<\/span>)<\/span> {<\/span>\n            auto<\/span> chunk<\/span> =<\/span> input<\/span>.<\/span>GetInputChunk<\/span>();<\/span>\n            auto<\/span> a<\/span> =<\/span> chunk<\/span>.<\/span>GetVector<\/span>(<\/span>0<\/span>).<\/span>GetView<\/span>();<\/span>\n            auto<\/span> b<\/span> =<\/span> chunk<\/span>.<\/span>GetVector<\/span>(<\/span>1<\/span>).<\/span>GetView<\/span>();<\/span>\n            auto<\/span> out<\/span> =<\/span> input<\/span>.<\/span>GetResultVector<\/span>().<\/span>GetDataMutable<\/span><<\/span>int64_t<\/span>><\/span>();<\/span>\n            for<\/span> (<\/span>idx_t<\/span> i<\/span> =<\/span> 0<\/span>;<\/span> i<\/span> <<\/span> chunk<\/span>.<\/span>GetRowCount<\/span>();<\/span> i<\/span>++<\/span>)<\/span> {<\/span>\n                out<\/span>[<\/span>i<\/span>]<\/span> =<\/span> a<\/span>.<\/span>Data<\/span><<\/span>int64_t<\/span>><\/span>()[<\/span>a<\/span>.<\/span>SelAt<\/span>(<\/span>i<\/span>)]<\/span> +<\/span> b<\/span>.<\/span>Data<\/span><<\/span>int64_t<\/span>><\/span>()[<\/span>b<\/span>.<\/span>SelAt<\/span>(<\/span>i<\/span>)];<\/span>\n            }<\/span>\n        })<\/span>\n        .<\/span>Register<\/span>(<\/span>extension<\/span>);<\/span>\n}<\/span>\n<\/code><\/pre>\n<\/div>\n<\/div>\n
You can use it as follows:<\/p>\n
\n
\n
LOAD<\/span> add_numbers<\/span>;<\/span>\nSELECT<\/span> add_numbers<\/span>(<\/span>40<\/span>,<\/span> 2<\/span>);<\/span>           -- 42<\/span>\nSELECT<\/span> add_numbers<\/span>(<\/span>40<\/span>);<\/span>              -- 42: b falls back to its default<\/span>\nSELECT<\/span> add_numbers<\/span>(<\/span>b<\/span> :<\/span>=<\/span> 2<\/span>,<\/span> a<\/span> :<\/span>=<\/span> 40<\/span>);<\/span> -- 42: named arguments work too<\/span>\nSELECT<\/span> add_numbers<\/span>(<\/span>40<\/span>,<\/span> NULL<\/span>);<\/span>        -- NULL, without the function doing anything<\/span>\n<\/code><\/pre>\n<\/div>\n<\/div>\n
You do not need re-target or rebuild it every time a new DuckDB version comes out. And nowadays, with all the AI tooling around, building an extension has never been easier.<\/p>\n
\n
\n
SET<\/span> allow_extension_repositories<\/span> =<\/span> 'allowed'<\/span>;<\/span>\nCREATE<\/span> EXTENSION<\/span> REPOSITORY<\/span> my_repo<\/span> FROM<\/span> 'https:\/\/extensions.example.org'<\/span>;<\/span>\nINSTALL<\/span> my_ext<\/span> FROM<\/span> my_repo<\/span>;<\/span>\nLOAD<\/span> my_repo<\/span>\/<\/span>my_ext<\/span>;<\/span>\n<\/code><\/pre>\n<\/div>\n<\/div>\n
A repository is a name, a URL prefix, and one or more RSA public keys that are trusted to sign the extensions served from it. The prefix can point at anything DuckDB can read: a local path, https<\/code>, s3<\/code>, you name it. At CREATE<\/code> time, DuckDB fetches the repository’s public keys and pins them into the repository definition, printing each key’s SHA-256 fingerprint so you can compare it against one published out of band. If you would rather not trust the network at all, you can pass the key directly:<\/p>\n
\n
\n
CREATE<\/span> EXTENSION<\/span> REPOSITORY<\/span> my_repo<\/span> FROM<\/span> 's3:\/\/my-bucket\/extensions'<\/span>\n    USING<\/span> PUBLIC<\/span> KEY<\/span> '-----BEGIN PUBLIC KEY----- ...'<\/span>;<\/span>\n<\/code><\/pre>\n<\/div>\n<\/div>\n
Pinned repositories survive restarts, support key rotation by trusting multiple keys, and can be audited at any time through the duckdb_extension_repositories()<\/code> table function, or removed again with DROP EXTENSION REPOSITORY<\/code>. Together with the stable C API, the extension story rounds out nicely: write your extension once, sign it, host it wherever you like, and INSTALL<\/code> it anywhere.<\/p>\n
These are only a few highlights, and this post is only a preview. Some details may still shift before the release this fall, and there are many more features and improvements that we could not cover here. DuckDB v2.0 will also come with a small set of breaking changes, including the new default storage format and the completed lambda syntax transition, which we will cover in detail in the release announcement.<\/p>\n
There have been more than 10,000 commits by many contributors since we released v1.5. We would like to thank our community for the detailed issue reports, feedback, and contributions that shaped this release. If you want a taste before the fall, the preview builds<\/a> have most of these features today, and if something breaks, you know where the issue tracker<\/a> is.<\/p>\n<\/p><\/div>\n
Source link <\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
Mark Raasveldt and Hannes M\u00fchleisen 2026-08-17 | 16 min TL;DR: DuckDB v2.0 is coming this fall. In this post, we preview its headline features: DuckDB as a server, triggers, the VARIANT type, asynchronous I\/O, a new SQL parser, a new storage format, and much more. DuckDB v2.0 will be named \u201cCyanoptera\u201d after the cinnamon teal […]<\/p>\n","protected":false},"author":16,"featured_media":23410,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[143],"tags":[],"class_list":["post-23409","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai"],"_links":{"self":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/posts\/23409","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/users\/16"}],"replies":[{"embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/comments?post=23409"}],"version-history":[{"count":0,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/posts\/23409\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/media\/23410"}],"wp:attachment":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/media?parent=23409"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/categories?post=23409"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/tags?post=23409"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Starting this fall, we will add a stakeholder advisory board to the DuckDB Foundation<\/a>. The advisory board will provide input on the development roadmap of DuckDB, DuckLake, and Quack. This allows key stakeholders to have a say in the projects’ direction.<\/p>\n
So you have written your extension. But how should you distribute it? Until now, DuckDB could only install extensions from the built-in repositories (core<\/code>, core_nightly<\/code>, community<\/code>, \u2026). In v2.0, you will be able to register your own trusted repositories (#24777<\/a>, currently work-in-progress), so an organization can host and sign its own extensions and have them install and load just like the built-in ones:<\/p>\n
Query planning also becomes partition-aware<\/strong> (#22336<\/a>). Lakehouse formats<\/a> (DuckLake, Iceberg and plain Hive-partitioned Parquet on S3) are all partitioned, and exploiting that partitioning is often the difference between scanning a dataset and skipping most of it. In v2.0, the planner and optimizer take full advantage of existing partitioning, and partitioned writes have been reworked as well (#22225<\/a>, #22620<\/a>).<\/p>\n
There is more: SQL-standard FETCH FIRST 2 ROWS ONLY<\/code> (#23533<\/a>), OVERLAY()<\/code> (#22456<\/a>), UNNEST<\/code> in GROUP BY<\/code> (#23644<\/a>), and well-defined MERGE<\/code> \/ UPDATE ... FROM<\/code> semantics for multi-matched rows (#24058<\/a>).<\/p>\n
The JSON mutation functions<\/strong> json_set<\/code>, json_insert<\/code>, json_replace<\/code>, and json_remove<\/code> (#23786<\/a>) finally let you modify JSON documents in place:<\/p>\n
The new variable syntax<\/strong> (#21194<\/a>) lets you write $x<\/code> anywhere an expression is allowed, no more getvariable(...)<\/code> verbiage<\/a>:<\/p>\n
Nested schemas<\/strong> (#23492<\/a>, #24222<\/a>) allow schemas within schemas:<\/p>\n
DML inside CTEs<\/strong> (#21634<\/a>, #21997<\/a>, #24217<\/a>) lets you use INSERT<\/code>, UPDATE<\/code>, DELETE<\/code>, and COPY<\/code> as pipeline steps:<\/p>\n
Running DuckDB long-term also comes with new challenges, which is why v2.0 pushes on better metrics, logs, and observability (see, e.g., the metrics layer rework in #22799<\/a>) that let you look at a DuckDB instance and see what it is actually doing. People even built standalone clients for the Quack protocol within weeks of the preview. We thought we were extending DuckDB to talk to other DuckDBs; the world said no, no, no, and built their own clients. Who would have thought.<\/p>\n
CONNECT<\/code> is the successor to the remote.query($$...$$)<\/code> workaround we showed when Quack was first revealed \u2013 we looked at that syntax and said: no, this cannot be it. And CONNECT<\/code> is not limited to Quack: it points your session at any remote database that supports it, and the new remote pushdown optimizer (#22914<\/a>) ships SQL directly to PostgreSQL and MySQL instead of pulling tables over the wire:<\/p>\n