TL;DR
Jordan Tigani, MotherDuck CEO and former BigQuery architect, joins Tristan Handy on The Analytics Engineering Podcast to argue that the agent era is playing out the way MotherDuck bet it would: most data isn't big, local-first single-node databases fit how agents actually work, and the data stack is about to look very different.
The MotherDuck and DuckDB relationship
MotherDuck is built on DuckDB but is a separate company. When Jordan first approached DuckDB Labs co-founders Hannes and Mark, they turned him down for a job but agreed to partner instead. DuckDB Labs got a co-founder share of MotherDuck, which aligned incentives without a heavily negotiated contract. The relationship runs on trust: DuckDB Labs builds custom features for MotherDuck (like write concurrency), attends board meetings, and receives funding for DuckDB development. MotherDuck gets a head start on the enterprise features DuckDB core deliberately leaves out — user models, auth, grant statements, backups.
Who uses MotherDuck
Most MotherDuck customers are smaller tech companies and startups moving off Snowflake, Redshift, or BigQuery. A growing group are AI companies building analytics into applications for their own end users. MotherDuck's hyper-tenancy model works well for that second group: each end user gets a separate DuckDB instance in the cloud, spinning up in under 100ms. For higher-concurrency workloads, read scaling lets you configure a pool of DuckDB replicas, with a median query time of 3 milliseconds server-side.
Why it's faster and cheaper
Distributed databases like BigQuery are built for throughput, not latency. Every query passes through multiple layers before anything actually runs. MotherDuck wraps a single-node engine optimized for low latency. On ClickBench, their standard instance at $2.40/hour beats Snowflake's 2XL at $64/hour by roughly 5x.
Small data, revisited
The "big data is dead" thesis has held up, but Jordan frames it differently now. There are two independent axes of scale — data size and compute size — and they don't always move together. Querying the last hour of logs from a petabyte dataset doesn't require big compute. MotherDuck handles the vast majority of real workloads. For cases that genuinely need more, DuckLake and Iceberg compatibility let customers hand off to Spark without losing access to their data.
ETL, agents, and what's coming
Jordan wrote that ETL is "highly vibe codable," meaning LLMs can generate connectors and SQL transformations without much trouble. He saw a company whose entire product was an MCP server running in Claude, with no separate frontend. That stuck with him. He's less sure where agents will drive analytical database usage specifically, but MotherDuck's architecture fits well: switching from local DuckDB to cloud MotherDuck is just changing a database name prefix from nothing to md:. Agents that start working locally can move to the cloud without reinstalling anything.
The agent swarm vision
Jordan's "Water-Town" blog post sketches a future where multiple agents collaborate around data: quality control agents running evals, observability agents flagging anomalies, context-curating agents pulling business definitions from user conversations. He thinks this layer will emerge either from a single provider or from companies assembling the pieces themselves. What holds it together is an analytical database that can handle the query load those agents generate without blowing up the economics. The MotherDuck MCP server and MotherDuck Dives are early pieces of that picture.
