Thunderduck vs Trino
Both query data where it lives instead of loading it somewhere first. Trino distributes one query across a cluster you run; Thunderduck runs each query in a container that did not exist a second earlier.
| Thunderduck | Trino | |
|---|---|---|
| Shape of the engine | Single-node DuckDB per query, started on demand and sized from the query's plan. | A coordinator plus workers, distributing one query across the cluster. |
| What you operate | Nothing. There is no cluster to size, tune or keep alive. | A cluster: worker count, memory limits, spill configuration, and a coordinator that must stay up. |
| Cost when idle | Zero. No instance exists between queries. | Workers are running whether or not anyone is querying. |
| Ceiling | One machine's worth of memory and CPU per query — generous, but a single machine. | Scales out. A join across sources far larger than any one node is what the architecture is for. |
| Sources | S3, GCS, Azure, PostgreSQL, MySQL, Iceberg (Glue and Nessie), BigQuery. | A large connector ecosystem, well beyond that list. |
| Cost visibility | Planned and priced before it runs; a budget can refuse the query. The estimate is a first-class answer, not a log line. | Resource groups and limits bound a query while it runs. |
| AI agents | A native MCP server — Claude and ChatGPT connect directly, with schema discovery, column meanings and a per-query cost ceiling. | JDBC or the REST API. Agent access is yours to build and secure. |
| Tenant isolation | A container per query, and optionally instances dedicated to one customer. | A shared cluster, partitioned by resource groups and access control. |
We agree about federation and disagree about clusters
Trino was right about the important thing: the data is already spread across object storage, warehouses and databases, and moving it all into one system to ask a question is a tax nobody wants to pay. Thunderduck starts from the same premise.
Where it differs is what answers the query. Trino distributes it across workers you operate — which is how it joins tables larger than any single machine, and also why there is a cluster to size, tune and keep running. Thunderduck runs each query in one DuckDB process that starts when the query arrives and exits when it ends. Most analytical questions fit comfortably on one modern machine; the ones that genuinely do not are the ones Trino is built for.
The honest trade: scale-out for zero operations
A single node has a ceiling. A join across two sources that each exceed one machine's memory is a Trino query, not a Thunderduck one, and we would rather say so than let you discover it in production.
In exchange there is nothing to run. No coordinator to keep alive, no worker count to guess, no memory limits to tune after a query spills. Compute appears per query, sized from that query's plan, and disappears — so a quiet week costs nothing rather than a cluster's worth of instances.
Knowing the cost before you run it
Federated queries are easy to get expensive: one missing predicate and you are scanning a whole partition set across the network. Thunderduck plans every query first, prices it, and can refuse it against a budget — which is also what makes it safe to let an AI agent explore, since its first instinct is rarely a selective filter.
Choose Trino when
- A single query has to join sources larger than one machine can hold.
- You need a connector we do not have yet.
- A platform team already runs the cluster and the tuning is a solved problem for you.
- Query load is heavy and continuous, so the workers are busy anyway.
Choose Thunderduck when
- You want federated SQL without operating a coordinator and workers.
- Load is spiky or occasional, and paying for idle workers grates.
- AI agents will be querying, and you want each query planned, priced and bounded.
- Queries fit on one large machine — which, for most analytical work, they do.
Federated SQL, minus the cluster.
Query across your sources with nothing to size, tune or keep alive.