Skippr Docs

Appearance

How MotherDuck Destination Authentication Works in Skippr ​

June 2026

MotherDuck destination authentication is token-based and compact, which is helpful as long as the token’s database and schema access matches where Skippr is expected to write.

Short Answer ​

MotherDuck destination authentication in Skippr uses a motherduck_token plus the target database and schema. The docs recommend sourcing that secret from MOTHERDUCK_TOKEN, which keeps the warehouse identity outside the checked-in config while the destination block stays focused on where data should land.

That gives the destination a very compact auth model. If Skippr is writing to database my_database and schema main, the token must still have write access there. A token that opens MotherDuck generally but cannot create or update objects in that namespace is not a sufficient destination identity.

Why Teams Struggle with This ​

Compact does not mean vague. The MotherDuck docs make it clear that the token, the database, and the schema belong together. Teams get into trouble when they treat the token like a blanket permission and only later discover that the chosen namespace is not actually writable.

  • Authentication is token-based, with the token usually supplied via ${MOTHERDUCK_TOKEN}.
  • The token must have write access to the selected database and schema, not just general account access.
  • Outbound network access to MotherDuck is still part of the destination auth picture because the runner must reach the service.
  • CDC-managed tables use MERGE semantics, so the same token must support ongoing writes and reconciliation, not merely a one-time bootstrap.

How Skippr Handles It ​

Skippr works well with MotherDuck because the destination contract is easy to read back to another engineer: one token, one database, one schema. There is very little hidden state, which makes both review and rotation simpler.

That clarity also matters for CDC. The destination docs and CDC docs describe a final-state warehouse behavior based on MERGE, _skippr_order_token, and tombstone tables. The token you grant should match that real operating pattern, not just a one-off file import.

  • Token-based authentication through ${MOTHERDUCK_TOKEN}.
  • Explicit destination scope through database and schema.
  • A documented requirement that the token can write to the chosen namespace.
  • CDC support aligned with DuckDB-style MERGE semantics plus order-token and tombstone protection.

What the First Useful Version Looks Like ​

The first useful version is one token and one dedicated raw schema. That proves the destination identity and keeps future object ownership clear.

If multiple teams share MotherDuck, avoid using a broad personal token for the pipeline. A dedicated token and namespace create a much cleaner destination auth model.