Hello world: the birth of Thunderduck

Hello world. This is the first post on the Thunderduck blog, so it may as well be the one that explains why Thunderduck exists at all.

The birth of Thunderduck

We kept watching the same project run in different companies. The data is already there — sitting in S3, GCS or Azure, plus a Postgres and a MySQL nobody wants to touch. Then someone asks a reasonable question: can our AI agents answer questions on our own data? And the answer comes back as a roadmap: first a warehouse, then pipelines to load everything into it, then modeling, then access control, then — six months later, and one invoice at a time — an agent gets to ask its first question.

We had built those platforms ourselves, so we knew what the six months were actually spent on. Not on analysis. On moving bytes from where they already lived into a place that would charge us rent for keeping them. Meanwhile the engine we were using for quick local checks — DuckDB — was answering the same questions in seconds, on a laptop, for free.

Thunderduck came out of that impatience: a serverless engine that goes to the data instead of demanding the data come to it, with a native MCP server so agents get the same governed access analysts do.

Our mission

Help companies enable AI on their own data faster, at a fraction of the cost, and natively integrated with any AI tool through MCP.

• Faster — exchange credentials in the console, let the engine discover your catalogs, and be AI-queryable in about five minutes. No pipelines, no migration, no data movement.
• Lower cost — you pay for the query-seconds you consume, not for idle compute waiting to be used. Data stays in your buckets in open formats, so leaving costs nothing but a deleted credential.
• Natively integrated — one MCP endpoint that any MCP client can point at: Claude, your IDE, your own agents. They discover schemas and run federated queries across the lake and your databases, inside budgets you set.

Our vision

Every company's data should be one endpoint away from any AI tool — governed, cost-checked and without a single copy being made. Not a data platform you migrate to, but a layer you point at what you already have.

That only works if exploration is safe. An LLM will happily full-scan 400 GB, because it never sees the bill. So every query — human or agent — gets a cost and runtime estimate before it runs, and anything over budget is blocked or rerouted rather than billed. Curiosity is free. Full scans aren't. We check first.

Two questions worth asking

If you take one thing from this post, take these two questions into your next data platform review:

Why are we paying this much — and why does it take at least six months before an agent can ask its first question?

Snowflake, BigQuery and Databricks are strong engines, and for plenty of workloads they are the right answer. But they share an assumption: the data gets loaded into them first. That assumption is where the six months go — ingestion, modeling, backfills, a migration plan — and it is what per-credit pricing on always-on compute is charging you for afterwards. The question isn't whether those platforms work. It's whether that trade is still the only way to get a question answered.

Our answer is no. Keep the data where it is, in open formats. Send the engine to it. Give analysts SQL and agents an MCP endpoint over the same catalog, with the same guardrails. Start Monday, not next quarter.

What's next here

Upcoming posts: running MCP in production, what pre-execution cost estimates actually catch, federating a lake with an OLTP replica without waking your DBA, and what our design partners' bills looked like before and after.

We named it after a duck for a reason — DuckDB does the heavy lifting. The thunder is ours.