Skippr Docs

Appearance

How to Explain MotherDuck Tables to Analysts ​

July 2026

Analysts should read Skippr MotherDuck tables as ordinary current-state tables in a database and schema, not as a mutation archive.

Short Answer ​

Explain MotherDuck tables as ordinary current-state tables in the configured database and schema. Skippr uses DuckDB MERGE semantics with order-token guards, so a CDC-managed MotherDuck table should be treated as the latest raw row set for each business key rather than as a ledger of every change event.

That keeps the table meaning simple. If my_database.main.accounts is the landing table, one row is the current raw account record after the most recent successful load. _skippr_order_token helps Skippr reject stale writes, and tombstone tables protect deletes, but analysts normally care about the business columns in the main table.

Why Teams Struggle with This ​

Because MotherDuck is easy to query, teams sometimes skip the explanation step and assume analysts will infer table semantics. That usually leads to people treating internal system columns as business data or expecting historical mutations from a table that is designed to show current state.

  • A CDC-managed MotherDuck table is generally a latest-row table, not a change-event archive.
  • The token, database, and schema determine where the table lives, but only the business columns describe the entity analysts are modeling.
  • The _skippr_order_token column protects ordering and is rarely the right field for business analysis.
  • Tombstone tables are operational companions for delete safety, not the usual place to start an analyst-facing model.

How Skippr Handles It ​

Skippr makes MotherDuck easy to teach because the destination surface is narrow: token, database, and schema. That means the analyst explanation can stay focused on the tables themselves instead of on a long platform checklist.

The CDC behavior is similarly straightforward. DuckDB MERGE semantics plus Skippr-managed tokens and tombstones let the destination behave like a simple current-state raw layer, which is exactly what many small teams want.

  • Targets one MotherDuck database and schema directly.
  • Uses DuckDB MERGE semantics for final-state CDC tables.
  • Automatically creates _skippr_order_token columns for stale-write protection.
  • Creates tombstone tables automatically so delete handling stays correct under retries.

What the First Useful Version Looks Like ​

The first useful explanation is one table in one schema, with one sentence about row meaning: this table shows the latest raw record for each key. That framing is usually enough to align analyst expectations.

If the team later wants a history layer, build it separately and name it clearly. The raw MotherDuck table should remain the dependable current-state base, not a hybrid of current state and event history.