DuckDB 2.0: Upgrade Now or Wait for 2.0.1?

DuckDB 2.0 is out. If your team runs 1.4 or 1.5, should you upgrade now or wait for 2.0.1? Did DuckDB 2.0 have more quality problems than we would expect after a release? We investigated using GitHub data we collected with vgi-github, the GitHub connector for VGI.

By comparing issue and contributor activity across 46 DuckDB-owned, user-facing repositories around 2.0, 1.4 and 1.5, we found that more people filed issues each day around 2.0, including more first-time reporters. Relative to each release’s baseline, we found a smaller rise in core-engine issue intake than at 1.5. Client and installer repositories received more issue reports than their baselines predicted, which may indicate problems with those components.

We counted issue reports across all versions and issue types. We have not classified which reports identify regressions introduced by 2.0, so we cannot turn these counts into a defect rate.

We counted 239 new issues on release day and the five days that followed. DuckDB’s issue activity was already growing, and increasingly common AI agents make it easier to write and submit reports. We compared recent releases against their own baselines to account for changing activity, although we cannot identify how many of these reports involved AI.

We smooth daily counts with a trailing seven-day mean. Dark gray lines and boxed labels mark 1.4.0, 1.5.0 and 2.0.0; smaller labels identify patch releases and the 2.0 alpha announcement. Daily counts ↓

To make the comparison meaningful beyond raw counts, we benchmarked each release against its own pre-release activity. Our baseline uses the average for each weekday in weeks 12 to 9 before release, so we compare a post-release Monday with earlier Mondays. We divide observed activity by that expectation: 1× means activity matched the baseline; 2× means twice the expected activity.

We align all three releases on day zero. This accounts for different starting levels and weekday patterns, but cannot isolate changes in adoption, reporting habits or workloads.

We found issue intake at 2.9× expected for 2.0, compared with 2.6× for 1.5 and 1.6× for 1.4. Accounting for the baseline narrows the gap between 2.0 and 1.5.

We divide trailing seven-day activity by its expected total. Before day 6, the curve includes pre-release days; the text compares days 0–5 only. The dotted line marks the planned 2.0.1 release on 18 November, day +28. Lines stop at observed data.

We found first-time reporting at 4.6× its expected level after 2.0, against 2.1× after 1.4 and 2.2× after 1.5. “First-time” means their first observed issue anywhere across the 46 repositories. Someone who previously filed against the engine does not become new again by filing against Python.

Daily reporter participation reached 3.4× baseline, while issues per reporter fell to 0.8× baseline.

Most first-time reporters filed in one repository: 67 of 72. Only 5 filed in more than one. Collectively, they filed across 16 repositories during the matched post-release window. These counts deduplicate people across the whole window. Reporter counts by repository breadth ↓

We have not measured whether these reporters represent a wider mix of users or workloads. An established DuckDB user can also file a first issue.

Trailing seven-day actual / expected activity. We count distinct people each day and exclude bots and unavailable identities. These are daily counts, not whole-week distinct-person totals.

We found 127 of the 239 issues in the core repository, or 53 percent. Clients, extensions, ecosystem projects and documentation accounted for the rest.

Our 2.0 core baseline predicted 49.75 issues, giving 2.55× expected activity. At 1.5, we counted 37 issues against 11.25 expected: 3.29× baseline. The engine’s increase was smaller at 2.0, despite the higher raw count.

We counted 27 client and installer issues against 11.25 expected, or 2.4× baseline. We repeated the comparison using the final four pre-release weeks: the core increase remained smaller than 1.5’s, and clients stayed above baseline at 1.9×. We cannot claim a larger client response than 1.5’s, because that ordering reverses between baselines. Both calculations ↓

We group all issue types and versions by the repository where reporters filed them. This does not identify which component caused a problem. “Ecosystem” comprises DuckLake, pg_duckdb, dbt-duckdb and duckdb-skills.

If you use Python and Iceberg, start with reports in those repositories. These links open issues from the observation window. We list sparse baselines separately because a few reports can produce a large multiple when the expected count approaches zero.

Extensions: Iceberg, Quack, DuckDB UI, HTTP / S3.

Language clients & installers: Rust, WebAssembly, Node.js (Neo), Python, Install scripts, Python CLI.

Extensions: PostgreSQL extension, MySQL, Spatial, Delta, Excel.

The first list has more issues than expected and at least one expected issue. The second has less than one expected issue or no established baseline. These are descriptive groupings, not confirmed regressions.

Repository counts and comparisons with 1.4 and 1.5 ↓

We tracked PR openings and daily participation by people with a merged PR. We chose people over raw merged-PR totals because an integration bundle can carry many changes in one PR.

PR openings, net of known supersession, moved from 2.1× baseline in the four weeks before 2.0 to 1.8× afterward. Merge participation stayed close: 1.47× before and 1.52× after. Contributors remained active; these counts do not identify which changes maintainers will ship in 2.0.1.

We count PRs opened by people and exclude known superseded or landed-elsewhere PRs. We classify supersession only in the core repository.

We count distinct PR authors each day and plot a trailing seven-day ratio. A bundle’s submitter did not necessarily author every change it contains.

We counted 88 issue closures, including 54 for issues opened before release. We have not classified fixes, duplicates or other closure outcomes, so dividing closures by new issues would not give a resolution rate.

The engine’s issue surge is smaller than 1.5’s once we account for activity before each release.

These counts do not tell us how severe the reported problems are or what business impact they have. A smaller surge does not necessarily mean a less disruptive release.

Clients and installers are receiving more reports than usual. We would start evaluating 2.0 now, paying particular attention to the clients and installers you use.

We would be more cautious about 2.0.1 if new reports stay high or we see no evidence of fixes.

Our current closure counts do not tell us how quickly maintainers fix confirmed bugs.

At Query Farm, we’re shifting our extension and development work to the DuckDB 2.0 branch. We’re watching progress on the 2.0 branches closely and working diligently on the first Haybarn release for DuckDB 2.0.

We’ll keep this report updated as more data becomes available.

We analyzed 46 user-facing DuckDB repositories through 26 October 2026 UTC. This preliminary report includes the engine, clients, extensions, ecosystem projects and documentation. We excluded the automated fuzzer, registries and CI tooling. Headline comparisons cover days 0–5 for all three releases.

We calculate weekday expectations from days −84 to −57 before each release. For window and trend ratios, we divide summed actual activity by summed expected activity. We retain raw daily bins, including day zero, and smooth the calendar with trailing seven-day means.

We also checked the final four pre-release weeks as a baseline. That gives 2.0 issue intake of 2.3× expected and first-time reporting of 2.6×. Our main baseline precedes 2.0’s alpha announcement; 1.5’s includes quieter year-end holidays.

With the alternative baseline, we find core intake at 2.38× for 2.0 versus 3.02× for 1.5. Clients and installers give 1.93× versus 2.08×; the main baseline gives 2.40× versus 2.26×. Changing the baseline reverses the client comparison.

We exclude bots and unavailable identities from people counts. We deduplicate people by GitHub user ID across the selected repositories and determine first issues separately from first PRs. The core history has 17 unresolved records, which can affect first-observed dates. We classify supersession only in the core and use latest closure timestamps without reconstructing reopen cycles. Repository moves and filing habits can affect comparisons. We withhold ratios for zero expectations or unestablished repository baselines.

GitHub links open live pages; downloads preserve our snapshot. Release dates come from DuckDB’s official calendar, checked on 27 October 2026. Planned dates can change.

If you need help with a DuckDB integration, application or upgrade, discuss your project with Query.Farm or email us a brief.

Query Farm now distributes its DuckDB 2.0 extensions through its own repository. Here's how to install them and why we're changing how we deliver releases.