DuckDB and Snowflake get compared as if they're competitors. They mostly aren't. They answer different questions, and picking the wrong one is how you end up either paying for a warehouse you don't need or outgrowing a laptop-sized tool in production. Here's how I decide.
They're built for different shapes of problem
Snowflake is a cloud data warehouse. It separates storage from compute, scales elastically, handles many concurrent users, and comes with governance, sharing and a large ecosystem. You point a cluster at your data and a hundred analysts can query it at once. You pay per second of compute, by the credit.
DuckDB is an in-process analytical database — think "SQLite for analytics." It runs inside your Python process, your laptop, or a single server. No cluster, no service to operate, no per-query meter. It reads Parquet and CSV directly, including files sitting on S3, and it is very fast on a single machine.
One is a rented warehouse with a loading dock and a staff. The other is a workbench in your own garage. The question is which one the job needs.
The decision usually comes down to four things
1. Does your data fit on one big machine? This is the one people get wrong. "Big data" is rarer than the marketing suggests. A single modern server handles hundreds of gigabytes to a few terabytes comfortably, and DuckDB is built to use all of it. If your working set is in that range — and most companies' is — a single-node engine is not a compromise, it's the right tool. If you're genuinely at tens of terabytes scanned per query, or petabytes at rest, that's Snowflake territory.
The number that matters is not your total data. It's the working set: the bytes a typical query actually touches. Columnar Parquet plus predicate pushdown means a query over a 2 TB table that filters to last month and selects six columns may read a few gigabytes. Teams routinely provision for the 2 TB and never measure the few gigabytes.
2. How many people query it at once? DuckDB is fundamentally single-node. It's perfect for one analyst, a transformation job, or an app backend serving queries it controls. It is not built for fifty analysts running ad-hoc dashboards simultaneously. Concurrency at that scale is exactly what Snowflake's elastic compute is for.
Be precise about what "concurrency" means for you, though. Fifty people with a dashboard open is not fifty concurrent queries — it's fifty mostly-idle browser tabs hitting a cache. Fifty analysts writing exploratory SQL at 10am on a Monday is concurrency. The first case a single node handles fine behind a result cache; the second it does not.
3. Who runs it, and do they want to run anything? Snowflake is zero-ops — there's no server to keep alive. DuckDB has nothing to operate either, but only because it lives inside something you already run. If you want a managed, hands-off, governed platform for a whole org, that's Snowflake. If you want a fast engine embedded in a pipeline or a notebook, that's DuckDB.
This is the question teams answer emotionally. "We don't want to manage infrastructure" is usually true and usually decisive — but notice that DuckDB-over-Parquet has no infrastructure to manage either. What it has is no vendor to call. Those aren't the same thing, and which one you're actually buying matters.
4. What's the cost model doing to you? Snowflake bills compute by the second against credits. That's elastic and fair when usage is spiky, and brutal when a scheduled job or a careless dashboard leaves a warehouse running. DuckDB's compute cost is whatever the machine it runs on already costs — often effectively zero, because it's your existing CI runner, app server or laptop.
The asymmetry worth internalising: Snowflake's bill scales with how you query, DuckDB's with what you already rent. A badly-written query on Snowflake costs money every time it runs. The same query on a box you're already paying for costs nothing extra — it's just slow, which is a problem you can see and ignore.
This is the first part. The full post — including the rest of the working details — is on my site: DuckDB vs Snowflake: the 4 questions that decide it
Top comments (0)