Skippr Docs

Appearance

What Access Skippr Needs to Write to MotherDuck ​

June 2026

MotherDuck write access is compact, but the token still has to own the target database and schema you expect Skippr to manage.

Short Answer ​

Skippr needs a MotherDuck token that has write access to the selected database and schema, and the runner needs outbound network access to MotherDuck. The connector docs keep it direct: motherduck_token, database, and schema are the whole warehouse surface, so the permission question is whether that token can create or update objects where the pipeline is supposed to land.

A practical setup is database: analytics and schema: raw with the token stored in MOTHERDUCK_TOKEN. When CDC is enabled, the write boundary still stays simple from an auth perspective, but Skippr uses DuckDB MERGE semantics plus _skippr_order_token columns and tombstone tables so the destination keeps one current row per key.

Why Teams Struggle with This ​

MotherDuck feels lightweight, which can hide real access issues. A token may be valid and the service may be reachable, but the wrong database name or a schema the token cannot manage will stop the warehouse path immediately.

  • The token must still have write access to the specific database and schema you configure.
  • The runner needs outbound connectivity to MotherDuck, which matters in locked-down CI or private-network environments.
  • Schema naming mistakes are easy to miss because the token can authenticate while still lacking the ability to create objects where you intended.
  • CDC is not append-only here; the token has to support maintaining final-state tables through DuckDB merge behavior.

How Skippr Handles It ​

Skippr matches MotherDuck well because the warehouse config is intentionally narrow. That makes access review easy to communicate: one token, one database, one schema, and one expectation that Skippr can create and update its managed tables there.

The CDC destination docs also remove guesswork about how writes behave. MotherDuck uses final-state reconciliation with automatic order-token columns and tombstones, so the token is being granted permission for a current-state table contract, not just bulk file loading.

  • Uses a single MotherDuck token rather than a multi-part credential bundle.
  • Needs write access on the configured database and schema.
  • Keeps credentials out of config through MOTHERDUCK_TOKEN.
  • Uses DuckDB-style final-state CDC reconciliation with order tokens and tombstones.

What the First Useful Version Looks Like ​

The first useful version is one MotherDuck database and one schema that are dedicated to raw landing so ownership is obvious and the token scope stays understandable.

If the token can authenticate but not create objects, fix the database and schema grants before you widen the pipeline because that is the real permission boundary.