Skippr Docs

Appearance

How MotherDuck Shapes the Warehouse Contract ​

July 2026

MotherDuck gives a compact warehouse contract when the team wants one database and schema of current-state tables without a lot of surrounding platform surface area.

Short Answer ​

MotherDuck shapes the warehouse contract around one database, one schema, and tables that act as the current-state interface for downstream SQL. The destination docs keep the connector small for that reason. Skippr writes into the selected location, adds _skippr_order_token VARCHAR, and creates tombstone tables so older replays do not override newer rows or resurrect deleted keys.

That means a config such as database: analytics and schema: main is already telling consumers where the contract lives. If orders lands in that schema, the main table is the thing dbt models and ad hoc queries should read. CDC behavior stays attached to that table through DuckDB-style guarded writes rather than through a separate event log the team has to reconstruct later.

Why Teams Struggle with This ​

MotherDuck can feel simple enough that teams skip contract design entirely. In practice, the same questions still matter: which database owns raw landing, which schema holds the tables, and whether everyone understands those tables as current state rather than append-only history.

  • A token can be valid while the chosen database and schema are still the wrong landing area for the pipeline.
  • Using one broad token across several environments can blur ownership even in a small deployment.
  • If analysts expect mutation history in the main table, the CDC contract will be misunderstood from the start.
  • Skipping tombstone behavior in the explanation makes delete safety harder to reason about during retries.

How Skippr Handles It ​

Skippr fits MotherDuck well because the connector does not add much surface beyond the real warehouse choices. You name the database and schema, keep the token out of config, and let the destination table remain the primary interface.

That simplicity also makes CDC easier to teach. Newer writes win only when their order tokens are newer, tombstones protect deletes, and the current-state table stays readable without a separate reconciliation layer in downstream SQL.

  • Targets a specific MotherDuck database and schema.
  • Keeps the destination contract centered on the main tables, not on staging mechanics.
  • Uses DuckDB-style guarded writes for CDC final state.
  • Adds _skippr_order_token and tombstone companions automatically.

What the First Useful Version Looks Like ​

The first useful version is one MotherDuck database, one schema, and one CDC-managed table with a business key the team can inspect directly. That proves the warehouse contract with very little extra surface area.

If environment separation matters later, keep the database and schema names explicit and rotate tokens per environment. The compact contract stays valuable only when its ownership stays clear too.