Why this exists

MotherDuck’s useful idea is not “DuckDB somewhere in the cloud.”

It is hypertenancy: per-tenant compute that scales to zero, sitting on a lake that does not move when you change placement. Most tenants are idle. Billing them like an always-on warehouse is how you lose money.

pdo is that shape on Cloudflare. Control plane in D1, Parquet in R2, SQL in DuckDB-WASM. When a query no longer fits a Worker, you graduate the duckling, not the dataset.

The problem with stuffing analytics in D1

D1 is SQLite. Fine for orgs and API keys. Bad for repeated full scans.

Same 1M ClickBench-shaped rows, in-process:

query	sqlite	duckdb	speedup
GROUP BY OSName	244ms	10ms	25×
region avg	235ms	2.4ms	98×

count(*) looks similar. Aggs do not. Columnar Parquet earns the WASM tax here. Row-store meters (D1 rows-read) punish you as soon as queries × rows_scanned climbs.

Why not just buy MotherDuck or ClickHouse

If you need…	Buy / use
Managed ducklings, IAM, SLA	MotherDuck
Firehose ingest, multi-TB warm scans	ClickHouse
Cloudflare-native, bursty tenants, DIY	pdo

pdo exists for the third row and for teaching the pattern. Pocket-change floor (~$5 Workers Paid). You own the sharp edges.

What it is for

• Embedded per-tenant analytics in a SaaS
• Bursty orgs, mostly idle
• Working sets that fit a Worker (think SF0.1 / ~1M-row facts)
• Proving placement-without-copy before you build a company around it

What it is not for

• A Snowflake replacement
• Sub-50ms p99 dashboards on cold isolates
• Continuous high-rate ingest
• Pretending 64MB of DuckDB is “unlimited serverless OLAP”

The product thesis is boring on purpose: same lake, disposable compute, graduate when physics says so.