DuckDB  · 

Who Actually Runs DuckDB, Measured from 110M Extension Loads

The companion to my post on DuckDB upgrade speed. Once you strip out the CI traffic that is 70% of my telemetry, the extension catalog isn't the monopoly the load counts imply or the flat field the raw config-days imply — and a third of real installations turn out to be on a desktop.

This is a companion to DuckDB Upgrade Speed, Measured from 110M Extension Loads, which explains the dataset and the counting method. The short version: I ship a telemetry client in Query.Farm’s DuckDB extensions that sends one small JSON payload per extension load. Counting loads directly is useless because a single autoscaling deployment can produce ten million of them, so I count config-days — one distinct combination of date, country, region, platform, DuckDB version and extension.

Seventy percent of those config-days come from continuous-integration jobs that load nearly the whole catalog every day. Every figure here excludes them, leaving selective config-days: configurations that loaded five or fewer extensions in a day. All of it comes from my own 34 extensions, so read it as the community-extension corner of the ecosystem rather than DuckDB at large.

What the catalog actually looks like

Counting only configurations that loaded five or fewer extensions in a day — selective config-days — gives a different answer.

Share of load events Share of all config-days Share of selective config-days
July 2026, all three series as percentages of their own total, on one 56% axis. quickjs is the argument in a single row: 56% of the loads, 2.1% of the selective population. hashfuncs moves the other way, because the loaders dilute it.

By events the catalog is a monopoly with one extension at 56%. By raw config-days it is a flat field where nothing exceeds 9.1%. Among configurations that behave like users it is neither: a leader at 20.3%, a second tier near 10%, and about eleven extensions carrying meaningful weight.

Uniformity in the raw totals isn't a property of the ecosystem. It's the shape of a CI matrix, reproduced 34 times.

Removing the loaders also changes the growth rate. The organic population went from 41.4 config-days a day in November to 340.9 in July — 8.2x, against the 3.9x headline. Automated traffic has been growing more slowly than the humans it was hiding.

Which extensions are spreading

Spread is reaching more locations; intensity is being used harder in the same ones. Raw config-days mix the two. Distinct locations separates them, and has to exclude WebAssembly — a browser visitor contributes one config-day from one location, so a demo page getting traffic is indistinguishable from adoption.

Extension Places, FebPlaces, Jul Organic config-days, Feb → Jul Share of organic population
datasketches1388121 → 1,2144.1% → 11.5%
rapidfuzz3397134 → 1,1134.6% → 10.5%
hashfuncs3273239 → 2,1458.1% → 20.3%
stochastic74817 → 4500.6% → 4.3%
a51551293 → 92210.0% → 8.7%
crypto3763378 → 50312.9% → 4.8%
shellfs3264229 → 6757.8% → 6.4%
http_client5173268 → 4369.1% → 4.1%

The organic population grew 3.6x over those five months, so an extension has to beat that to hold its share. Three do. datasketches is the clearest case: 13 locations to 88 with usage per location barely moving, which is spread almost unmixed with intensity.

crypto and http_client show the opposite. Both grew in absolute config-days, both reached more places, and both lost more than half their share — the two most-adopted extensions I shipped in November are now mid-pack. a5’s apparent jump to 155 locations is 97 one-shot WebAssembly visitors; its native footprint went 15 to 51, slightly behind the population.

Two limits on all of this. DuckDB nightly -dev builds each count as a distinct configuration — 3.0% of the organic population overall, but 85% of one extension’s, where a single developer building against main produces sixty config-days in a month. And selective config-days identify loaders that behave like CI, not loaders that are CI; the empty band in the histogram is the evidence for the cut, not the threshold itself.

Platforms, and who isn’t there

The CI traffic is entirely linux_amd64 in cloud regions, so it distorts the platform mix more than any other question in this dataset. Counted raw, x86 Linux is 82.7% of config-days and DuckDB looks like a server-only database. Among configurations that behave like users, it’s 46.3%.

Share of all config-days Share of selective config-days
Whole-window figures across all 14 platform strings, six shown, both series on one 82.7% axis. Every platform except x86 Linux roughly triples once the CI traffic is removed, because CI is exclusively x86 Linux in cloud regions.

A third of real installations are on a desktop. macOS ARM and Windows together are 33.5% of selective config-days, against 10.6% of the raw total. Measured by load events — where one autoscaling deployment can vote a hundred thousand times — DuckDB is a 60.5% ARM Linux database and the desktop barely registers. Measured by the configurations that behave like users, x86 Linux holds a plurality rather than a supermajority, and macOS ARM, ARM Linux and Windows sit within four points of each other.

ARM Linux is the one platform that genuinely grew: 9.9% of selective config-days in November, 20.6% in July.

Two absences are worth naming. Intel Macs are gone — osx_amd64 is 0.4% of the last complete week, and I’d stop treating it as a tier-one target. WebAssembly is small but not the rounding error the raw numbers imply: 2.67% of selective config-days, 1,221 in nine months. How much of that is “few people load community extensions in a browser” and how much is “the telemetry request doesn’t survive a browser” I can’t separate, and the number shouldn’t be read as the first when it might be the second.

Per-extension, the platform mix is stranger than the totals. shellfs, which pipes shell commands in and out of DuckDB, is 44.6% Windows — by far the most Windows-heavy thing I ship, on the platform where the shell it wraps is least like the one it was written for. a5 is 32.8% Windows and 22.5% macOS, making it the most desktop-bound extension in the catalog.

WebAssembly is concentrated in three extensions: vgi at 49.6% of its own installations, a5 at 11.7%, datasketches at 9.7%. vgi and a5 are both geospatial, which is the thing people clearly want in a browser.

Geography moves further than any other cut. Raw, this looks like an almost entirely American user base: 83.2% of config-days are US. Among selective configurations the US is 43.5% — still the largest by a distance, but under half. Germany triples to 7.7%, China to 4.7%, the Netherlands to 3.8%, and Sweden, Great Britain and Ireland each land at 3.1%. The 83% figure was mostly a map of where us-east-1 is.

DuckDB DuckDB Extensions Telemetry Query.Farm Data Engineering

Related reading