How MotherDuck Scales: a New Kind of Distributed Architecture

TL;DR

• MotherDuck is not a single-machine database. It's a distributed architecture where each query runs on one high-performance DuckDB node, while the platform spans hundreds of machines.
• Scale vertically by moving to larger Duckling instances, from Pulse and Standard up to Jumbo, Mega, and Giga. Giga matches a Snowflake 3XL in hardware.
• Scale horizontally with hypertenancy. Every user, customer, and agent gets an isolated Duckling, so a SaaS product runs hundreds of Ducklings at once.
• Attach read-scaling replicas to fan read-heavy BI and agent workloads across dozens of instances without competing for shared resources.
• There's no fixed data size ceiling. Query gigabytes to petabytes via DuckLake on object storage without ingestion.

What MotherDuck actually is

MotherDuck is not a single-machine database. It's a serverless data warehouse built on DuckDB, with a distributed architecture that spans hundreds of independent machines. The confusion comes from conflating two separate things: how an individual query runs, and how the platform as a whole scales.

Each query runs on a single high-performance DuckDB node. That's a deliberate design choice, not a limitation. A single node means no data shuffling between machines, no inter-node coordination, and no distributed query overhead, which is what gives MotherDuck sub-second latency. Distributed engines like Snowflake and Databricks break a query into fragments, coordinate across nodes over the network, and shuffle intermediate results. Every one of those steps adds latency. MotherDuck skips them.

The platform scales through hypertenancy, which gets a dedicated section below. In short, every user, customer, and AI agent gets one or more Ducklings, so a product serving thousands of end customers runs thousands of Ducklings at once across independent machines. That's what makes MotherDuck distributed at the aggregate level, without distributed query execution.

There's no fixed data size ceiling. MotherDuck handles workloads from gigabytes to petabytes. You can query petabytes of data sitting in S3, GCS, or Azure, including Iceberg and Delta Lake tables, without ingesting it first. DuckLake covers large-data, small-compute scenarios like logs and observability, where you write a lot but read only recent slices. Storage and compute stay separate, so data size and query speed scale on their own terms.

Vertical scaling: instance tiers for large single-query workloads.

The first way you scale MotherDuck is up. Pick a bigger Duckling when a single query needs more horsepower, and the tiers run Pulse, Standard, Jumbo, Mega, Giga.

Pulse sits at the entry point and bills per query in compute-unit seconds rather than wall-clock time. You pay for the work a query does, not for a warehouse sitting warm between clicks. For sporadic or bursty traffic, that metering matters more than raw speed, since a Snowflake warehouse keeps burning credits on a 60-second minimum whether or not anyone is querying.

Standard covers most interactive analytics and dashboard traffic. On ClickBench it runs at roughly 65% of a Snowflake XL's speed for about 5% of the cost, which is the tier where you land if you're moving off a small Snowflake warehouse and want your bill to drop by an order of magnitude.

Jumbo matches Snowflake's best performance at $4.80 an hour against roughly $192 an hour for the equivalent Snowflake setup. Same query times, 40x cheaper. It's the tier for read-heavy BI where latency is the constraint and you don't want a distributed cluster to get it.

Mega finishes ClickBench in 5.9 seconds. A Snowflake 3XL takes 14.1 seconds, so Mega is about 2.4x faster at $12 an hour versus roughly $128, which works out to 16x cheaper for the workload. A single vectorized node beats multi-node MPP here because there's no data shuffling between machines to slow it down.

Giga matches a Snowflake 3XL in hardware and handles the largest single-query workloads MotherDuck runs. Very few workloads need more than Giga, and the ones that do are usually multi-petabyte batch jobs better served by a different pattern.

Horizontal scaling via hypertenancy

Hypertenancy is what makes MotherDuck a distributed platform. Every user, customer, and AI agent gets one or more dedicated DuckDB instances, called Ducklings, and each one spins up in around 100ms and shuts down when idle. A SaaS product that provisions one Duckling per end customer runs hundreds or thousands of Ducklings at once, spread across independent machines. Add up all those instances and the aggregate compute spans hundreds of machines simultaneously, even though no single query ever leaves its own node.

Two production deployments show the pattern working at scale. Dexibit runs a per-customer instance architecture and treats capacity as elastic. "If we need to handle a load spike or a huge amount of queries, we can spin up more Ducklings on demand," says CTO Ravi Chandra, contrasting it with the pain of doing the same on Postgres. Together AI runs 128 concurrent self-service users across 40 read-scaling replicas, with AI agents querying unconstrained (covered in detail in the read-scaling section below).

MotherDuck holds up under load because each tenant runs in isolation. Snowflake handles concurrency by piling workloads onto a shared virtual warehouse, so a heavy query from one user degrades latency for everyone else on that warehouse until you provision more capacity or split traffic. Databricks routes work through a shared cluster where executors compete for the same memory and CPU, and one runaway job starves the rest. A Duckling has no neighbors. One user's expensive scan cannot slow another user's dashboard, because they run on separate machines.

That same isolation makes cost predictable per tenant. An agent querying a Standard Duckling cannot run up Giga prices no matter how many queries it sends, so a rogue or looping agent caps out at its own instance size rather than draining a shared pool. Pricemedic uses this at two levels of granularity, provisioning per-organization and per-user service accounts. "We were able to identify specific organizations, and even better, specific users, who need more compute. We can scale individually for each one," the team reports. You scale the tenants that need it and leave the rest alone, instead of resizing one cluster for the whole platform.

Read-scaling replicas for concurrent BI and agent workloads

Read-scaling replicas solve the concurrency problem that a single Duckling can't handle alone. Attach replicas to one compute instance, and MotherDuck fans a read-heavy workload across multiple Ducklings that share the same data. Each reader gets a dedicated instance, so a hundred users running dashboards never queue behind one another. The query itself still runs on a single node, so you keep sub-second latency while the platform serves many readers at once.

Together AI attaches 40 read-scaling replicas to serve 128 self-service Hex users, with their AI agents running unconstrained on top of it. Replicas absorb the spiky, parallel read load that BI tools and agents generate without a shared cluster to bottleneck them.

Replicas also cap your cost exposure, which matters when agents drive query volume you can't predict. The instance size fixes the price ceiling per replica and a runaway agent hits a compute wall, not a runaway bill. Give each agent its own replica, and one misbehaving agent can't degrade latency for the others or blow through a shared budget. You scale reads by adding replicas, cap spend by choosing instance sizes, and keep every query fast because none of them coordinate across machines.

Why single-node execution produces sub-second latency at warehouse scale.

A distributed query pays a tax before it does any useful work. The planner splits the query into fragments, ships them to worker nodes, and shuffles intermediate results back over the network to merge them. Every shuffle is a network round trip, and every fragment boundary is a chance to wait on the slowest node. On a Snowflake virtual warehouse or a Databricks Spark cluster, that coordination runs on every query, whether the data is 10 gigabytes or 10 terabytes.

MotherDuck runs each query on one DuckDB node, so none of that happens. No fragments, no shuffle, no waiting on a straggler worker. DuckDB's vectorized engine processes columns in batches with predicate pushdown and late materialization, and it does it without JVM startup or garbage-collection pauses, which Spark carries on every executor.

The ClickBench numbers show the gap. MotherDuck Mega finishes in 5.9 seconds against Snowflake 3XL's 14.1 seconds, roughly 2.4x faster on the same hardware class. Against a Databricks X-Large cluster running 32 workers, Mega is 4.6x faster (5.9s versus 27.3s), per MotherDuck's Databricks comparison. The 32-worker cluster loses because coordinating 32 executors costs more than the work saves at this scale. Distributing a query only pays off once a single machine genuinely can't hold the working set.

That threshold exists, and it's worth naming honestly. Multi-petabyte batch ETL with wide joins across massive tables, and large-scale ML training, are workloads where splitting across nodes wins. Databricks is built for the ML case, and Snowflake handles multi-petabyte distributed batch well. If your job needs more memory than a Giga instance provides, distributed execution is the right tool.

Most interactive analytics never approaches that line. DuckLake keeps petabytes in object storage while each query touches only the slice it needs, so the working set stays inside one node even when total data is enormous. For dashboards, ad-hoc SQL, and agent queries, single-node execution is what delivers sub-second latency, and it's a structural property of the architecture, not a benchmark you can only hit on a friendly dataset.

MotherDuck vs. Snowflake vs. Databricks: architecture compared

The three platforms take different approaches to running a query, and those differences drive everything downstream. The table below draws on the first-party comparisons at motherduck.com/vs/snowflake-alternative and motherduck.com/vs/databricks-alternative.

Pick MotherDuck when you need fast interactive queries, customer-facing analytics, or AI agent workloads, and you want predictable cost with no infrastructure to manage. Snowflake fits enterprise teams running multi-petabyte batch ETL who already have the expertise to tune warehouses and absorb the credit model. Databricks suits ML training and complex Spark pipelines, which is why many teams keep Databricks for ML and route the SQL analytics and serving layer to MotherDuck.

Conclusion

MotherDuck runs each query on a single high-performance DuckDB node, so you skip the coordination and shuffle overhead that slows distributed engines. The platform still scales out. Hypertenancy gives every user, customer, and agent an isolated Duckling, and read-scaling replicas fan read-heavy workloads across dozens of instances. Data ranges from gigabytes to petabytes through DuckLake on object storage, with no fixed ceiling.

If you already know DuckDB is fast, the next step is to run your own queries against it. Start on the Lite tier with 10 GB of storage and 10 compute-hours a month, no credit card required. Point it at your object storage, run a query that has been painful elsewhere, and watch the latency. You will learn more in ten minutes of real queries than in any comparison table.