MotherDuck

DuckDB, hosted. Same adapter, same semantics.

Every destination receives the same layout; see the tables Ingest creates.

Setup

The shortest setup here: one token, no network configuration, no cloud account. MotherDuck is hosted DuckDB, so Ingest connects as a service token and creates schemas in a database you name.

1. A database

In the MotherDuck UI, create one, or use the my_db you already have. The name must be a plain identifier: letters, digits, underscore and hyphen.

2. A token

Click your organization name (top left) → Settings → + Create token. Name it something you will recognise later (ingest), leave the type as Read/Write, and choose whether it expires. It is shown once.

A token carries the access of the account that created it; there is no narrower scope, so treat it as a credential for the whole database and rotate it in the same place if you ever need to revoke Ingest.

What to paste

Database and Service token.

Then test it

Test connection creates a scratch schema and a table, writes a few rows through the same load path a real run uses, reads them back to check the count is exactly right, round-trips pipeline state, and drops the lot. The first connection can be slow: DuckDB downloads and installs its motherduck extension the first time it runs.

Staging

needs_staging: none. Staging always happens in the destination's own cloud and region; data does not take a detour through ours.

Conformance

Every adapter passes the same suite before it ships: create a table with every canonical type, append 100k rows, atomic replace, merge (latest dedup_sort wins; child tables delete-then-insert by root id), schema evolution, NULL-key rejection, package replay without duplicates, state and schema round-trip, row-count read-back, identifier edge cases, double-underscored table names (__quarantine, child tables), and rollback on a mid-load failure.