Limits
The Worker envelope is sized for Cloudflare-native, scale-to-zero analytics. These numbers are the contract. When you hit them, see Scaling.
Envelope
| Constraint | Value |
|---|---|
DuckDB memory_limit | 64 MB |
| Threads | 1 |
| Parquet working-set gate | 48 MB |
| WASM binary | ~41 MB (~9.9 MiB gzip) |
| Paid Worker gzip cap | 10 MiB |
Cross the working-set gate and the engine refuses — time to scale up compute, not move the lake.
Sweet spot
- TPC-H SF0.1 (~21 MB, 600k lineitems)
- ClickBench-style 1M hits (~5 MB)
- Warm count / groupby / modest joins in hundreds of ms
- Many idle tenants, bursty queries
Graduate or scale up
See Scaling for Worker → native paths. Quick reference:
- Multi-GB hot working sets on Workers → native duckling, same R2 prefix
- High-cardinality aggs past 64 MB (
pnpm memory-boundary) - Firehose ingest → batch Parquet into R2
- Hard sub-50ms p99 SLOs → warm native or managed OLAP
Platform
Workers Paid is required. Free tier caps at 3 MiB gzip; DuckDB alone is ~10 MiB — hence the split control + engine Workers.
Latency shape
Warm engine wall ~150–300ms on sample groupbys. Client often 400–800ms. Occasional 2–3s outliers with a still-fast wallTimeMs → routing / cold isolate / view reload, not slow Parquet scans.