Skippr Docs

Appearance

How to Review MotherDuck Warehouse Config Before Production ​

July 2026

MotherDuck review is simple on the surface, which makes it even more important to confirm the exact database and schema boundary before production use.

Short Answer ​

Review a MotherDuck warehouse config by checking motherduck_token, database, and schema, then confirming that the token can create or write objects in that exact location. Production review should also verify that the team wants the documented final-state CDC behavior built on DuckDB MERGE semantics rather than a pure append-only landing zone.

That can stay small and concrete. If the config points at database: analytics and schema: main, the review should ask whether that is the intended raw landing area and whether the runtime has outbound access to MotherDuck. Once that is true, the CDC destination docs explain the rest: Skippr manages _skippr_order_token columns and tombstone tables so newer writes beat stale replays and deletes stay protected.

Why Teams Struggle with This ​

MotherDuck is compact enough that teams can assume the details will sort themselves out. In practice, the production questions are still real: which database and schema own the raw tables, who controls the token, and whether downstream users understand these as current-state CDC tables.

  • The token must still have write access to the selected database and schema before the first useful load can succeed.
  • A small warehouse does not remove CDC review requirements around replay safety and delete handling.
  • The chosen database and schema should be stable names the team is willing to document and keep.
  • Outbound connectivity to MotherDuck is part of production readiness, not an afterthought.

How Skippr Handles It ​

Skippr keeps MotherDuck easy to review because the connector surface is only token, database, and schema. That gives teams a very clear checklist before promotion.

The CDC behavior is equally direct. Skippr maintains final-state tables with guarded writes, automatic order-token columns, and tombstone companions so replay safety and delete safety stay visible even in a lightweight warehouse.

  • Uses a simple MotherDuck token plus database and schema configuration.
  • Requires only outbound connectivity to the MotherDuck service.
  • Supports final-state CDC through DuckDB-style MERGE semantics.
  • Creates order-token and tombstone structures automatically for CDC-managed tables.

What the First Useful Version Looks Like ​

The first useful version is one database, one schema, and one CDC-managed table that shows the team how MotherDuck will behave under retries and deletes.

If the token ownership model or raw-schema naming is still loose, tighten those now. Small stacks stay maintainable only when the boundary is explicit.