How big can data get before DuckDB stops being enough?

DuckDB is comfortable well into the tens of gigabytes on a single machine. Our public builds run 4 million rows monthly and hold a 27.5-million-row lake in 437 MB of partitioned Parquet — nowhere near its ceiling.

What does a DuckDB warehouse cost to run?

Zero for infrastructure: DuckDB is free, Parquet is a file format, and a GitHub Actions cron reruns the whole build monthly on the free tier. Our measured cloud run completes in 29 seconds.

When is a cloud warehouse worth paying for?

When many people and tools query the same data at once, when BI seats and permissions matter, when data outgrows one machine, or when compliance requires managed governance. Those are real needs — just usually not year-one needs.

Should a Startup Use DuckDB Instead of a Cloud Warehouse?

Q: Should a startup use DuckDB instead of a cloud warehouse?

At typical startup data sizes — millions of rows, gigabytes not terabytes — yes, start with DuckDB. It runs the same SQL and dbt workflow for $0/month. Move to a cloud warehouse when concurrency, seats, or scale genuinely demand it.

At the data sizes most startups actually have — millions of rows, not billions — yes: start with DuckDB. It runs real SQL, works with dbt, and costs $0/month. We didn't benchmark this in a lab; we run it in public.

What can DuckDB actually handle?

More than a year-one startup produces. Our $0 warehouse models and tests 4,090,836 rows and re-runs itself monthly on a GitHub Actions cron — the measured cloud run takes 29 seconds, infrastructure bill $0. Our incremental Parquet lake holds 27,485,631 rows in 437 MB, and each refresh reprocesses ~15% of it — one partition, not the whole history. DuckDB is comfortable well into the tens of gigabytes on one machine.

What do you give up without a cloud warehouse?

Four real things: concurrency (DuckDB is a single-process engine — one writer, no fleet of dashboards hammering it), seats (no managed access control for a growing team), scale (past what one machine holds, distributed engines win), and managed governance (audit trails, compliance certifications). If those describe your quarter, pay for Snowflake or BigQuery without guilt.

Why not just start in the cloud anyway?

Because the bill arrives before the need does. A warehouse you pay for idles most of the day at startup scale, and the free tiers push you toward their meters. The DuckDB + Parquet + dbt stack is portable by construction — your models are SQL and your storage is open files, so graduating to a cloud warehouse later is a migration, not a rewrite.

What does the honest decision look like?

Count three numbers: your total data size (fits comfortably on one machine → DuckDB), your concurrent readers (a scheduled report and a couple of humans → fine; twenty live dashboards → cloud), and your team (one data person → DuckDB; a department with permissions needs → cloud). Start free, measure, and move when a number says so — not when a vendor does.

Key takeaways

At startup sizes, DuckDB does the warehouse job for $0/month — proven monthly in public, 4M rows in 29 s.
The stack is portable: SQL models + Parquet files mean graduating later is a migration, not a rewrite.
A cloud warehouse earns its bill on concurrency, seats, scale, and governance — real needs, rarely year-one needs.
Decide on measured numbers (data size, concurrent readers, team), not vendor defaults.

Keep reading: the $0 warehouse case study and Stop rebuilding the whole pipeline.