they typically target larger, persistent workloads

This contrast is really about where each product expects the hard part of analytics to live. MotherDuck starts from a developer opening DuckDB, loading files or app data, and getting fast answers without standing up clusters or learning a full lakehouse stack. Databricks and BigQuery are built to be central company systems, where teams run ETL, notebooks, governance, and large shared workloads that justify much broader infrastructure and more people managing it.

• MotherDuck is built around DuckDB and serverless usage patterns that fit engineers and smaller teams. Its own positioning emphasizes fast analytics, embedded use cases, and per user compute isolation, while internal research notes DuckDB works best on sub 10TB workloads before distributed systems become more attractive.
  1 sacra 2 motherduck 3 motherduck
• Databricks sells a much wider operating environment. Databricks SQL sits beside notebooks, Delta Lake, ML tooling, workflows, and model serving, and serverless compute has expanded beyond SQL into notebooks and pipelines. That makes it powerful for a large data platform team, but also heavier than a tool a developer can adopt in an afternoon.
  4 sacra 5 databricks 6 databricks
• BigQuery Editions were designed for enterprise scale economics. Google tied editions to autoscaling capacity and compressed storage billing, which is useful when a company is continuously storing and querying large shared datasets. That model fits persistent warehouse and lakehouse spend, not the lightweight, local first workflow that made DuckDB popular.
  2 motherduck 7 google

The direction of travel is clear. The big clouds will keep moving downmarket with simpler serverless packaging, while MotherDuck keeps moving up from single developer workflows into production apps and shared analytics. The winners will be the products that preserve DuckDB level simplicity even as customer workloads become more collaborative, persistent, and enterprise controlled.