Improving DuckDB After 2.0 — November 5, 2026 Update

Since DuckDB 2.0.0 was released on October 21, seven of our new core fixes have merged, and 13 new code and build pull requests remain open across the DuckDB organization. We have also filed 17 issues, including reports that DuckDB maintainers have resolved with their own fixes.

Building DuckDB extensions and maintaining Haybarn exposes problems at the boundaries: named arguments reaching the wrong binding path, browser threads waiting on extension loads, and test paths failing on Windows. An extension cannot repair every part of that chain, so we bring reproductions and proposed fixes to the upstream projects that own it.

The statuses below are current as of November 5, 2026. Rusty Conover submitted this work on behalf of Query Farm; the contribution inventory lists each submission and its dates. Two older core submissions also merged during this period and appear in a separate section.

Select a status badge to view its referenced items.

Where the work landed

Those problems reach beyond the engine repository. Our new submissions span five repositories in the duckdb/ organization, including its build tooling. Community extension registry activity is excluded. Draft PRs count as open.

Seven new core fixes have merged

Our extensions need named options to reach the right function arguments. But in a correlated table-function call, DuckDB could treat a named option as another positional input. The same failure reproduces with the built-in range function:

SELECT count(*)
FROM (VALUES (3)) AS input(n),
     LATERAL range(input.n, hello => 123);

range has no option called hello. Before the fix, this query returned a count of 120 because the binder treated 123 as a second positional argument. With the fix, it reports an invalid named argument. Extension functions that declare named options receive those options correctly. PR #27833 includes the regression tests.

Fixing the binder therefore helps both built-in functions and extensions. It is one of seven new core fixes that have merged, covering SQL behavior, query execution, and extension testing.

But an upstream merge is only one step toward getting a fix to users. These seven PRs merged into main after 2.0.0 shipped, so they are not included in the released 2.0.0 binaries, which remain the latest stable engine release at this snapshot. A requested backport still needs to land on the release branch and ship before users receive it in a stable release.

Open work for extensions and applications

The remaining work needs more than a release containing the merged fixes. Eight new core PRs remain open: some correct existing behavior, while others give extensions information or control that the engine does not yet expose.

○Open Arrow union correctness. #27854 proposes a fix for how Arrow union type IDs select their members. DuckDB reads the schema’s mapping but then uses the raw ID as an index. Data using IDs such as 5,9 can be rejected; swapped IDs can silently select the wrong values. The proposal follows the declared mapping and validates it, addressing an older report.

○Open Checks and diagnostics for extension-defined SQL. #27986 would let an extension inspect a statement before a PRAGMA expands or a connected catalog executes it remotely. #28148 would let an extension add parameter guidance to a parser error while preserving DuckDB’s diagnostic. Both arose from Crossfield, where model definitions can supply information the parser does not have.

APIs for remote scans and storage. Checking a statement is only the start: once it runs, the engine and the extension must agree on the filters, columns, and request settings they exchange. Three proposals address gaps in those interfaces:

• ○Open #28090 would let a table function request join bounds it can send to another system, instead of Bloom or prefix-range filters that depend on engine memory.
• ○Open #28089 would let storage extensions distinguish virtual columns available during a scan from those they can actually return after a DELETE.
• ○Open #28088 would allow HTTP parameters to be copied through a virtual method, preserving provider-specific fields when a request needs different settings. Its companion, ✎Draft HTTPFS #512, awaits the core change and an updated DuckDB dependency.

○Open Progress that reflects completed work. But even a query that executes correctly can mislead its caller: some queries finish while their reported progress remains far below 100%. Two proposals address separate causes: #28413 would exclude a result-collector pipeline that never runs from progress accounting, and #28422 would account for materialized CTE pipelines fed directly by their producers.

Build improvements beyond the engine

Correct engine behavior is only part of delivering an extension or browser package. The same code still has to pass through build workflows, and those workflows can repeat work or wait on tasks they do not need. That led to four proposals to shorten the build process; all remain open.

○Open In extension-ci-tools, #456 would forward VCPKG_HOST_TRIPLET into Linux build containers. The workflow sets this variable, but the container does not receive it, so host dependencies such as protobuf and gRPC can build unnecessary debug variants. We found this while building Airport for Haybarn. Passing the variable through would let the container use the intended release configuration.

○Open Three DuckDB-Wasm proposals would remove avoidable CI work: #2292 would allow compilation to begin alongside test-data generation; #2294 would remove duplicate workflow triggers for new refs; and #2296 would skip native engine source checkouts in JavaScript jobs that consume already-built Wasm.

Reports that helped upstream fixes

But a useful upstream contribution does not always require us to write the fix. A reproduction can give a maintainer enough information to diagnose the problem or connect it to work already underway. Of our 17 new issues, seven are closed: our PRs resolved four, and DuckDB maintainers supplied fixes for the other three. Ten remain open.

• ✓Fix merged Aggregate memory reservations. Work on DataSketches exposed repeated export and import of aggregate states despite ample memory. Our report #28040 reproduced the behavior with DuckDB’s built-in list() aggregate. Laurens Kuiper’s fix #28065 merged on October 29.
• ✓Fix merged Python 3.14 shutdown. Our report #714 documented crashes and hangs when daemon threads scanned Python objects or Arrow data during interpreter shutdown. These failures persisted after an earlier fix. Evert Lammerts’s fix #719 merged on October 27; the report closed the following day.
• ✓Fix merged Parser settings within one submission. #27832 tracked settings such as integer_division failing to affect later statements in the same query string. Denis Hirn already had fix #27321 under review. It merged on October 26, and the maintainer identified 2.0.1 as the intended release in the issue discussion.

○Open Five open issues accompany the proposals above: three Wasm CI reports, query progress, and join-filter pushdown. The other five concern Windows compiler compatibility when loading extensions, commit callbacks interrupted by another callback’s exception, repeated copying of large constant values, function parameter discovery, and source row numbers for CSV and JSON readers. The last two request missing capabilities.

Earlier submissions with progress since release

But some of the progress since 2.0 came from proposals opened before the release.

✓Merged Two PRs opened before October 21 merged on October 26, in addition to the seven new core fixes. #25941 adds ADBC statement progress so clients can poll while a statement executes or its result stream is consumed. #26409 corrects named-parameter type metadata in duckdb_functions(). Its closing discussion identifies it as a 1.5 issue that does not affect 2.0.

But merging those two proposals does not finish the earlier work. Nine older PRs with activity during this period remain open:

×Closed without merge A closed PR can also mean the problem was solved another way. Nine earlier PRs closed without merging during the period; upstream changes superseded our Wasm heap-view fix, Node extension-download fix, and CLI result-draining error fix. We closed the shared-transaction proposal in anticipation of upstream work and the Python subcursor proposal because it had been implemented differently.

×Closed without merge The remaining closures were HTTPFS cancellation, which we are keeping in Haybarn for now; HTTP response decompression; a nanoarrow dependency update; and Quack documentation corrections, whose discussion points to documentation now maintained in duckdb-web. None of these closed PRs is counted as a merge.

Continuing the upstream work

These outcomes are why upstream work remains part of developing Airport, DataSketches, Crossfield, and Haybarn. The outcome may be our patch, a maintainer’s fix, or an upstream change that makes our proposal unnecessary. Sharing the problems our workloads expose gives other DuckDB users a chance to benefit from the same work.

We appreciate the DuckDB maintainers who have reviewed these changes and fixed the problems we reported. We will keep bringing that work upstream as we develop our extensions and distribution.