Numbers
Re-run with pnpm bakeoff or hit the live API. Not a formal ClickBench submission.
DuckDB vs SQLite (≈ D1)
1M ClickBench-shaped rows, same SQL, in-process.
| query | sqlite | duckdb | speedup |
|---|---|---|---|
| count | 2.2ms | 0.5ms | 4× |
GROUP BY OSName | 244ms | 10ms | 25× |
| region avg + limit | 235ms | 2.4ms | 98× |
| filter + groupby | 156ms | 7ms | 23× |
count(*) alone may be fine on D1. Aggs on column data belong on DuckDB over R2.
Live checks
https://rubberduck.b-christopher-3rd.workers.dev · Bearer demo-token
| check | result |
|---|---|
count(*) lineitem (container) | 600,572 |
count(*) hits | 1,000,000 |
| warm WASM lineitem count p50 | ~174ms wall |
| warm OS groupby p50 | ~172ms wall |
| client p50 (WASM) | ~500–800ms |
Containers add cold-start after sleep; local cache does not survive sleep.
Cost sketch
Demo traffic near the $5/mo Workers Paid floor, plus Container awake time, plus R2. Samples (~27 MB) are noise.
D1 rows-read hurts full scans: roughly 25k 1M-row groupbys/month before Paid overage dominates. Workers/Containers meter time instead. That is the economic case for lake + DuckDB on bursty traffic.
Managed warm pools and BI drivers are a different invoice (MotherDuck, ClickHouse, etc.).