DuckDB Upgrade Speed, Measured from 110M Extension Loads — Rusty Conover
DuckDB<br>·
August 5, 2026
DuckDB Upgrade Speed, Measured from 110M Extension Loads
Nine months of telemetry from Query.Farm's DuckDB extensions — 110 million loads — show each release landing slower than the one before it. Fourteen days in, v1.5.0 reached 33.7% of the population I can see; v1.5.5 reached 12.1%. The decline survives excluding CI traffic, excluding the v1.4 LTS line, and restricting to patch releases only.
Nearly every DuckDB release since v1.5.0 has been adopted more slowly than the one before it. Fourteen days after first appearing, v1.5.0 was running on 33.7% of the population I can see; the four that followed reached 26.4%, 21.1%, 12.3% and 15.3%, and v1.5.5 managed 12.1%.
I can see this because the telemetry client I ship in Query.Farm’s extensions sends one small JSON payload each time an extension loads: 110,413,978 events over 270 days, across 111 countries and 14 platforms. Nine columns wide, no device identifier, nothing about the data being queried. All of it comes from my own 34 extensions, which bounds everything below — not DuckDB itself, not the rest of the community catalog, not anyone who uses DuckDB happily without ever installing one.
That population isn’t a random sample either. These are people who went looking for something the engine doesn’t ship, and who therefore depend on somebody rebuilding that extension for each new engine version. That biases the level: this group should sit further behind than a DuckDB user carrying no extensions at all. It does not explain the trend, and a population that is itself growing and changing composition could produce a falling curve without anyone slowing down. I can’t rule that out, and it’s the weakest joint in the argument.
Extension loads are not installations
The telemetry payload carries no device identifier. That was the right privacy call and I’d make it again, but it means I cannot count people. I can only count loads, and loads are wildly unequal: a laptop that opens DuckDB twice a day and one cloud deployment whose containers restart a hundred thousand times an hour land in the same column.
Group every event by the identifying fields the payload does carry — extension, DuckDB version, platform, country, region — and 110 million events collapse into 9,397 distinct combinations. The ten largest are 61.33% of the entire dataset . The biggest is one extension, on one DuckDB version, on linux_arm64, in one AWS region in Ohio: 15,078,763 loads by itself. Meanwhile 1,687 of those 9,397 combinations were seen exactly once in nine months.
Any statistic computed per-event is therefore mostly a statistic about a handful of autoscaling policies.
If you count extension loads, you're measuring one customer's autoscaler. If you count places, you're measuring everyone else.
So I changed the unit. Rather than counting loads, I count a config-day : one distinct combination of date, country, region, platform, DuckDB version, and extension. A deployment that loads an extension ten million times in one region on one day contributes exactly one. A laptop that loads it once also contributes exactly one.
One day, counted two ways
Every load recorded on 4 August 2026. However many times a source loaded that day — 121,799 or once — it becomes a single config-day.
Loads that day Counts as
quickjsarm64 · Virginia
121,799
quickjsarm64 · Oregon
105,146
hashfuncsamd64 · Virginia
46,590
hashfuncsamd64 · Virginia · v1.4.3
36,104
one laptop59 like it that day
1,259 otherscombined, not one source
300,741 across all of them
1,259
the whole day
610,381 loads
1,264
Counted as loads, quickjs is 54.5% of that day across all its rows, and the catalog looks like a monopoly. Counted as config-days, quickjs is 2.8% and it's one extension among many. Neither number is wrong. They answer different questions.
Bars are scaled to the largest single source; the four named rows are the top four groups by load count that day. The deployment that loaded 121,799 times and the laptop that loaded once both count as 1 . That flattening is what makes the unit useful, and it's also what the unit can't see: a hundred separate people on the same platform in the same cloud region collapse together too.
That gives 164,445 config-days. Seventy percent of them come from configurations that load nearly the entire extension catalog every day.
Two populations, and nothing in between
Every config-day in the window, grouped by how many extensions that configuration loaded that day.
19–32 extensions<br>nearly the whole catalog
70.1%
1 extension
20.4%
2–5
7.4%
6–18
2.1%
164,445 config-days. The 6–18 band matters most: at 2.1% it is essentially empty, so the split is a gap in the data rather than a threshold I picked.
In July that traffic is 42 configurations in 11 country/region pairs — all linux_amd64 in cloud regions, present on 20 to 31 days out of 31, loading 28 to 32...