MotherDuck

MotherDuck is a managed, serverless cloud data warehouse built on top of DuckDB, offering fast, in-process SQL analytics without the need to manage any infrastructure.

What Weld supports

Weld integrates with MotherDuck in three ways:

• ELT destination — sync data from any of your Weld sources into MotherDuck. Weld supports append, merge and full-copy load strategies, and will automatically create and evolve destination tables (including adding new columns) as your source schemas change.
• Reverse-ETL / Activate source — use tables and views in MotherDuck as the source for Reverse-ETL syncs, so you can push data from MotherDuck out to your business tools.
• Data Warehouse querying — run ad-hoc SQL against MotherDuck from Weld's query builder and use it to power custom reports.

Before you connect

Pick your region carefully

A MotherDuck Organization is scoped to a single cloud region, chosen when you sign up, and it cannot be changed afterwards — moving means creating a new Organization and migrating your data.

Weld's infrastructure runs in AWS eu-central-1 (Frankfurt). Choosing the same region for your MotherDuck Organization keeps sync latency and cross-region data transfer to a minimum. Other regions work, but every sync will pay a round-trip penalty.

What Weld needs access to

Weld stores data in two databases, WELD_LANDING and WELD_MODELS (described in How Weld organises your data). Weld creates both automatically the first time it connects, so the account behind your Service Token needs permission to create databases.

If you'd rather not grant that, create the two databases yourself before connecting:

CREATE DATABASE IF NOT EXISTS WELD_LANDING;
CREATE DATABASE IF NOT EXISTS WELD_MODELS;

🔧 Setup Guide

Weld connects to MotherDuck using a Service Token, which is a token you generate from the MotherDuck UI. A token is required — Weld runs headless in the background and cannot complete an interactive browser/SSO login, so connections without a token cannot be created.

1. Log in to your MotherDuck account.

2. Create a dedicated service account for Weld, then go to Settings → Tokens and create a read/write access token for it.

Using a service account rather than a personal token matters for two reasons: the token isn't tied to a specific person, so it won't stop working when a team member leaves; and MotherDuck runs each account on its own compute instance, so Weld's syncs won't compete for resources with your own queries and dashboards.

3. Copy the generated token — you'll need it in the next step.

4. In Weld, when adding a new MotherDuck connection, provide:

• Service Token — the token generated in step 2. Required.
• Database — the name of the MotherDuck database (catalog) to connect to. Optional — if left empty, Weld will connect to your default database. This is the database you'll browse when importing existing tables into Weld; it does not affect where syncs or models are stored.

5. Press Connect. Weld will validate the token by running a test query against MotherDuck.

Once connected, you can start syncing data into MotherDuck, use it as a source for Activate, or query it directly from Weld's query builder.

How Weld organises your data in MotherDuck

MotherDuck grants access per database, all-or-nothing — there are no schema- or table-level grants. Weld therefore separates raw ingested data from your modelled data at the database level, so you can share one without exposing the other:

So a deals table synced from a HubSpot connection lands as WELD_LANDING.hubspot.deals, and Weld creates the view WELD_MODELS.WELD_RAW.hubspot__deals over it. Reference the view in your models rather than the landing table directly.

How values are stored

• Nested values from your sources — JSON objects and arrays — are stored as VARCHAR containing JSON, not as DuckDB STRUCT or LIST types. Use DuckDB's JSON functions to unpack them in your models.
• Every synced row carries a _weld_synced timestamp.
• For database sources with CDC enabled, rows deleted at the source are flagged rather than removed: Weld sets _weld_deleted_at on the matching row so you keep the history. Filter on _weld_deleted_at IS NULL in your models to see only live rows.

Compute and cost

You hold your own billing relationship with MotherDuck, so it's worth knowing how Weld's workload maps onto their pricing:

• Ducklings other than Pulse bill wall-clock time, and keep billing through a configurable cooldown (anywhere from 1 minute to 24 hours) after the last query finishes. A sync holds a connection open for the length of the load, so the load plus the cooldown is billable. If your syncs are short and frequent, a short cooldown — or a Pulse Duckling, which bills per query with no cooldown — will usually cost less.
• Materialised models are rebuilt in full on every run. Weld drops and recreates the table rather than updating it in place, so a large materialised model is billed for a complete rebuild each time its schedule fires. If a model is expensive and rarely changes, consider a less frequent schedule or leaving it as a view.
• Giving Weld its own service account (see the setup guide) also helps here: MotherDuck gives each account its own compute instance, so you can tune Weld's Duckling size and cooldown independently of the ones your team uses interactively.

Limits

• Ad-hoc queries run from Weld's query builder are cancelled after 10 minutes.
• Model materialisations are given up to 2 hours before Weld cancels them and marks the run as failed.