Introduction

Thunderduck

Thunderduck is now at thunderduck.ai. Old thunderduck.io links redirect, and existing API tokens and drivers keep working. If you use Thunderduck through MCP (the claude.ai connector, ChatGPT or Claude Code), remove it and add it again with https://mcp.thunderduck.ai/mcp, then sign in.

Thunderduck queries the data you already have, where it already is.

You register a catalog — a Postgres or MySQL database, a BigQuery dataset, an Apache Iceberg catalog, a bucket of Parquet/CSV/Excel files — and then query across all of them with one SQL dialect, from the console, a JDBC client, dbt, your BI tool, or an AI assistant.

Nothing is copied into Thunderduck to make that work. A query is planned, priced, and executed against your sources; only the rows it returns pass through the platform, and those are deleted after a day unless you save them.

How a query runs

  1. You submit SQL. The catalog references in it are resolved to the systems they belong to, and the statement is checked for syntax.
  2. It is planned and priced. The plan is bound against your live catalogs and an estimated scan size is produced. Too expensive, or an unfiltered scan of a large external table, and it is refused with a reason instead of being run.
  3. It executes in an isolated container sized from that plan, with your catalog credentials resolved at the last moment from a secrets manager.
  4. Results come back paged, with the SQL, timings, CPU, memory and row count recorded in your query history.

Where to start

  • Quickstart — connect a catalog and run your first query.
  • Catalogs — every source type, and how to address tables in each.
  • AI assistants — connect Claude or ChatGPT and query in plain language.
  • Clients & tools — JDBC, SQLAlchemy, Superset, dbt.
  • Reference — accepted SQL, limits, and the security model.