Skippr Docs

Appearance

What Network or Staging Access MotherDuck Needs ​

July 2026

MotherDuck destination access is simple on purpose: the runner needs outbound access to MotherDuck and a token that can write to the chosen database and schema.

Short Answer ​

MotherDuck needs outbound network access from the runner to MotherDuck, plus a token with write access to the selected database and schema. The destination docs define the connector around motherduck_token, database, and schema, so the useful load path is one authenticated outbound connection into one named MotherDuck database rather than a multi-stage staging workflow.

That simplicity is useful, but it still needs to be real. If the warehouse is my_database.main, the runner must be able to reach MotherDuck from its execution environment and use the token to create or update objects in that exact namespace. When CDC is enabled, the same write path also has to support the documented DuckDB-style MERGE behavior with order tokens and tombstones.

Why Teams Struggle with This ​

MotherDuck usually fails for fewer reasons than the larger warehouse connectors, which is good, but it also means the remaining reasons stand out sharply: no outbound access, the wrong token, or a token that reaches the account but not the intended database and schema.

  • The runner needs outbound network access to MotherDuck from the real job environment.
  • The token has to be valid and still authorized for the selected database and schema.
  • Schema creation and write privileges matter even when the connector surface is small.
  • CDC final-state behavior still depends on the warehouse path being able to create and update the managed tables.

How Skippr Handles It ​

Skippr matches MotherDuck well because the destination path stays narrow: one token, one database, one schema. That is easy to hand to a small team because there is no extra object-store staging layer to reason about before the first load works.

It also means you can test the real path quickly. If the runner can connect with MOTHERDUCK_TOKEN, write into my_database.main, and read back the landed table, then both the network and auth boundary are already clear enough to support later CDC work.

  • Uses token-based authentication through MOTHERDUCK_TOKEN.
  • Targets one explicit database and schema.
  • Requires only outbound network access to MotherDuck in the documented setup.
  • Supports CDC final-state tables with automatic order-token and tombstone handling.

What the First Useful Version Looks Like ​

The first useful version is one MotherDuck token, one database, one schema, and one small table load that proves the token can create and write objects there.

If the warehouse still feels mysterious after that, keep the scope small. MotherDuck is easiest to run when the database boundary is simple and explicit.