Thunderduck vs DuckDB
Thunderduck runs on DuckDB. The difference isn't the query engine — it's everything a team needs around it to run DuckDB for more than one person.
| Thunderduck | DuckDB | |
|---|---|---|
| Deployment model | Managed SaaS, in your own cloud (BYOC), or fully on-prem. | No deployment to pick from — a library you embed yourself. Hosting, infrastructure and setup are entirely manual. |
| Multi-user access | Shared service — every user signs in with their own identity. | Single process, single user; no server, no multi-tenancy. |
| Concurrency & isolation | One right-sized container per query; no noisy neighbours. | Threads inside one process; one writer at a time. |
| Resource sizing | CPU, RAM and disk chosen per query from its own plan. | Manual — you size the host and set memory limits yourself. |
| Federation | Postgres, MySQL, BigQuery, ClickHouse, files on S3/GCS/Azure, and Iceberg catalogs (AWS Glue or Nessie) — connected with credentials in the console. | Extensions exist (postgres, mysql, httpfs, iceberg), but you install, configure and maintain them on every host. |
| Catalog & schema discovery | Automatic on connect — tables, columns, types, row counts. | None — you attach and introspect yourself. |
| Semantic layer | Column meanings inferred then human-confirmed; roles tagged; PII flagged. | None. |
| AI access | Native MCP server — OAuth per user, read-only by default, every query cost-gated. | None natively; community MCP servers exist, with no governance. |
| Cost control | Cost and runtime estimated before execution; budgets can refuse a query. | None — a query runs until it finishes or runs out of memory. |
| Result caching | Identical read-only queries served from a prior result within the TTL, at zero compute cost. | None. |
| Access control | Role-based, read or write per catalog. | None — OS file permissions only. |
| Audit | Every query logged with the user, token or client that ran it, plus source and cost. | None. |
| Transformation | Scheduled SQL and dbt runs on the same engine. | dbt-duckdb adapter exists; scheduling and orchestration are yours to build. |
| Lakehouse writes | CREATE TABLE AS SELECT into Iceberg on AWS Glue or Nessie. | Iceberg support is read-oriented; catalog integration is limited. |
| Connectivity | JDBC driver, SQLAlchemy dialect and REST API against a shared endpoint. | Client libraries against a local file; no remote endpoint. |
| Monitoring | Query history, plans, estimates vs. actuals, usage per source and per user. | None. |
| Version upgrades | Managed. | Self-administered, host by host. |
| Support | Direct from the team building it. | Community. |
| Feature development | Requests go into the product roadmap. | Community-driven, unpredictable timing. |
The engine underneath is the same DuckDB
We are not claiming to have built a faster DuckDB, and we haven't. It is a genuinely excellent embedded analytical engine — vectorized, fast on a single machine, and correct about the trade-offs an in-process library should make. There is no reason to reinvent that part, so we didn't.
What DuckDB does not have an opinion on is what happens the moment a second person, a second data source, or an AI agent needs the same access. It was never designed to answer who is asking, what they are allowed to touch, or what a query is about to cost — because as a library, it assumes one trusted caller. Thunderduck is that layer.
One process becomes one right-sized container per query
DuckDB's ceiling doesn't change: one query still runs on one machine's worth of memory and CPU, the same as it would embedded in your own process. Thunderduck doesn't pretend otherwise — a join that needs a distributed engine is still a job for something else.
What changes is who provisions that machine and when. Instead of one process you size once and keep alive, every query gets its own container, sized from that query's own plan, and gone the moment it finishes — so ten people running occasional queries never fight over one host's memory, and nobody is paging anyone about a process that fell over.
Governance is the part a library was never built to have
A single-user embedded database correctly has no login, no audit log and no budget — there is nobody to distinguish it from. That stops being true the instant the caller might be a teammate, a dashboard, or an LLM that never sees the bill and will happily scan the whole table to answer one question.
Thunderduck plans and prices every query before it runs, so a budget can refuse one; logs every query against the person, token or agent that ran it; and gives AI agents a native MCP connection with their own identity and a cost ceiling, rather than a raw connection string to your data.
Choose DuckDB when
- You're the only user: a notebook, a CI job, a one-off analysis on your own machine.
- Nothing needs to be shared, governed or logged — it's your process, your file, your call.
- You want the smallest possible footprint: no network, no credentials, no service to reach.
- An AI agent will never touch this data without a human directly in the loop.
Choose Thunderduck when
- A second person, team or AI agent needs the same data through their own identity.
- Credentials to a real source — Postgres, S3, a warehouse — shouldn't live on a laptop.
- Every query should be planned, priced and logged, before and after it runs.
- You want DuckDB's engine without becoming the person who patches, sizes and monitors it.
Same engine. Now it's a service.
Connect your data and let a right-sized container run the query — nothing to embed, size or keep alive yourself.