At Trunkrs, a Dutch same-day delivery company, the morning meeting had a small obstruction: a dashboard that made people wait. The team wanted to investigate yesterday’s sorting problems and delivery delays. Each pause made another question less attractive. A database had acquired the power to decide when a conversation was over.
- MotherDuck adds managed cloud analytics to the open-source DuckDB engine.
- Local-cloud queries and isolated user compute are its architectural calling cards.
- Its customer stories make speed a question of working habits, alongside cost.
Trunkrs moved from Redshift to MotherDuck, running the two warehouses in parallel while transferring sources. It kept Looker, using pg_duckdb as a proxy. The company reports snappier responses and deeper investigations. The copyable detail is pleasantly unromantic: make a working counterpart, then migrate in stages. Revolutions are easier to enjoy with a rollback plan.
The engineer who made big data smaller
MotherDuck’s wager begins with Jordan Tigani, a founding engineer on Google BigQuery. He had helped build a system for distributing analytical work across machines. MotherDuck’s founding announcement argued that better hardware had changed the calculation: many ordinary workloads no longer needed that elaborate machinery. The industry’s appetite for scale had outlived some customers’ need for it.
DuckDB supplied the engine for another approach. It is an embedded analytical database, comfortable inside a program or on a laptop. MotherDuck supplies the managed cloud service around it. Local and remote data can participate in the same SQL statement, with execution divided between client and cloud. A developer can keep a familiar DuckDB workflow while gaining shared infrastructure.
The company’s origin has the amiable messiness of a side project becoming a business. Looker founder Lloyd Tabb supplied the name and introductions; DuckDB Labs became an organizational co-founder. The initial team met in Seattle in June 2022. Their product’s working name, EasyQuery, was considerably less entertaining.
A duckling of one’s own
A shared warehouse can resemble a dinner party where one guest orders for the table. MotherDuck’s answer is hypertenancy: separate compute for individual users, with instance sizes adjusted to their workloads. Read replicas provide another way to accommodate read-heavy demand. A customer who needs more processing need not require everyone else’s resources to grow.
Own computeUser B
Own computeData job
Own compute
PriceMedic makes that distinction concrete. It works with a 100TB healthcare pricing lake, but extracts customer-specific slices of roughly five million rows. In its published account, query times fell from seven seconds to about half a second. It also reports roughly $20,000 in monthly savings after removing expensive transformations and reducing other AWS costs. Those are results of its particular redesign, rather than a discount promised to every buyer.
“We can scale individually for each one.”
Josh Nakka, PriceMedic co-founder
The revealing number is the slice, not the lake. Total stored data can be a poor guide to the work a query actually performs. Teams comparing warehouses should measure that work, its concurrency and its cost before choosing the grandest architecture in the catalogue.
The application that waited for its own database
Stern Risk Partners had a more direct problem. Its Rails application, extraction jobs, dbt transformations and dashboards all used one Heroku Postgres database. Transformation runs locked it for two hours. A failed run meant another attempt and another delay. Here the first thing to fail was application access.
The brokerage moved analytical transformations to MotherDuck while retaining Postgres for the application. Files travelled through S3; selected results returned to Postgres. With model optimization, the team reports a seven-minute dbt build. Separate service accounts handled ingestion, production transformations, validation and dashboards. This is a useful pattern for teams whose application database has become an accidental warehouse.
Reflex, which connects retailers with on-demand workers, describes a related separation. It moved reporting off production Postgres, using dlt for ingestion, dbt for transformation and Metabase for analytics. The attraction is practical: keep useful tools, give analytical queries somewhere more appropriate to run, and stop making production carry every new question.
What the bill buys
MotherDuck occupies the space between running DuckDB yourself and adopting a broader warehouse platform such as Snowflake, BigQuery or Redshift. ClickHouse and Databricks also enter the comparison, depending on the workload. MotherDuck sells managed operation and collaboration around an engine developers can already use independently.
As checked on October 6, 2026, its Business plan starts at $250 per organization per month plus usage; a free plan and custom Enterprise offering are available. Compute and storage still matter. “Serverless” relieves customers of managing servers, while leaving them with a bill to understand. MotherDuck announced $47.5 million across Seed and Series A financing in 2022, followed by a $52.5 million Series B in 2023.
Trust has acquired its own product work. In February 2025, MotherDuck announced SOC 2 Type II and GDPR compliance, alongside business features and support options. Its expertise includes operating DuckDB in production, not merely attaching a cloud address to a database.
The warehouse learns to prepare dinner
By 2026, the product was extending into work around the query. Flights runs Python pipelines; Dives produces interactive data applications with AI agents; managed DuckLake offers open lakehouse storage. In August, MotherDuck acquired Tower, whose runtime already powered Flights. September brought commercial support for open-source DuckDB and Jev-powered text classification inside SQL.
These additions widen the proposition from storing answers to preparing and presenting them. They also make evaluation more specific. A transactional application still needs a database suited to its transactions. Large scans, remote data transfer and simultaneous readers deserve workload tests; an attractive customer result cannot settle those questions. Self-hosted DuckDB may be sufficient when one person needs local analysis.
MotherDuck’s most useful argument remains the morning meeting. A fast answer gives someone room to ask another question. The sensible test is whether your team uses that room - and whether the cost of providing it survives contact with your own data.