MotherDuck

The gap between a laptop and a warehouse

Analytical tooling divides oddly by scale.

At the small end there are files and scripts. Someone has a few million rows in a file and analyses them on their machine. This works well and it does not share, it does not scale, and it does not connect to anything else.

At the large end there are cloud warehouses. These handle enormous volumes and many users, and they require data to be loaded into them before anything can be asked.

The gap between these is wide, and a great deal of real analytical work sits in it. Datasets of a few gigabytes. One or two people. Questions that begin with a file somebody already has.

Starting from DuckDB

DuckDB occupies the small end well. It is an analytical database that runs inside a process rather than as a server, storing data by column so analytical queries perform properly. There is nothing to install as a service and nothing to connect to.

Its limits are the obvious ones. It runs on one machine, so it is bounded by that machine, and there is no shared place for data to live.

MotherDuck adds cloud storage and compute around that engine, and the important detail is that it does not replace the local engine.

Queries across both

Because the engine exists in both places, a query can reference tables held locally and tables held in the service, executing across both.

The practical effect is worth stating plainly.

An analyst has a file on their machine, perhaps something exported from another system or produced during their own work. There is also a dataset held centrally that the team maintains.

Joining these conventionally means uploading the local file somewhere first. That is a step, it takes time, and it produces a copy in a place it does not belong.

Here the local file stays local and is joined to the cloud dataset in one query.

This suits how analysis actually proceeds. Work begins with what someone has, and reaches for shared data when it needs to.

Where the scale argument lands

It is worth being clear about what this does not attempt.

It is not built for the volumes and concurrency that cloud warehouses address. An organisation with terabytes queried by hundreds of people needs a warehouse, and this is not one.

What it addresses is the substantial amount of analysis below that threshold, which currently either happens in isolation on individual machines or is forced onto a warehouse that is more infrastructure than the task warrants.

The honest positioning is a different point on the scale rather than a competitor at the top of it.

Sharing without copying

Datasets held in the service can be shared.

The alternative in the small scale world is sending files. Someone produces an extract and emails it, or puts it on a shared drive. The recipient now has a copy that stops matching the original immediately, and when the analysis is repeated next month nobody is certain which version anyone used.

A shared dataset that colleagues query removes that. There is one dataset rather than a growing set of divergent copies.

Who uses it

MotherDuck is used by analysts, data scientists and small data teams working with datasets that do not require warehouse scale infrastructure, and by people who prefer analysis that begins with the files in front of them rather than with a loading exercise.

Points to consider

MotherDuck is a commercial cloud service and the official documentation is the reference for capabilities, limits and pricing.

Scale suitability should be established honestly. For very large volumes or high concurrency, a warehouse remains the appropriate tool, and choosing otherwise creates problems later.

Hybrid execution means data moves between local and cloud during a query. How much moves depends on the query, and network conditions affect the experience in a way that purely local or purely cloud execution does not.

DuckDB itself remains available and free to use directly. Where the requirement is genuinely local analysis with no sharing, the service adds capability that may not be needed.

Getting started

The official documentation covers connecting, storing data in the service, and hybrid queries. Attaching the service from a local DuckDB session and joining a local file to a cloud table demonstrates the central idea in a few minutes, which is the clearest way to judge whether it fits how you work.