MotherDuck

Use it when

• Your data measures in tens or hundreds of gigabytes and a single fast node beats paying for idle distributed capacity.
• Local development should be production: the same DuckDB SQL, extensions, and clients run on the laptop and in the cloud, with Dual Execution splitting queries between them.
• You want a shared, always-available warehouse on top of a DuckDB workflow the team already likes.
• Cost at small scale is the deciding factor against Snowflake or BigQuery.

Think twice when

• Data or concurrency genuinely outgrows a single node per query; ducklings scale up and replicate for reads, not out across a cluster.
• Streaming ingest is required; there is no Kafka sink, so events stage through object storage or a partner connector.
• The stack is not AWS; the service runs in four AWS regions (though it queries GCS and Azure data).

How it runs

Fully managed: each query runs on a single-node DuckDB "duckling" that starts in about 100 ms, billed per second by instance size, over managed storage or DuckLake, with Iceberg read/write and Delta read. A read-scaling replica pool serves concurrent readers. The free tier is single-user; paid tiers add hybrid execution and teams.