Migrate to MotherDuck

Start Here: Is a MotherDuck Server Active?

Use an active remote MotherDuck MCP server or local MotherDuck server to inspect the in-scope database, schema, grain, keys, and relevant metrics. Reuse known context and narrow discovery to the requested work; do not scan the whole workspace by default. Let the actual data model shape the result.

Resolve the target from the request or active context. Ask only if ambiguity materially affects the result. Without a server, use supplied schema and explicit assumptions for planning; do not imply live validation.

Migration Defaults

• native MotherDuck storage first
• pg_duckdb when extending an existing PostgreSQL estate is the least disruptive path
• validate before cutover
• port SQL dialect and data types deliberately before performance tuning
• phased cutover over big-bang replacement
• remote DuckDB database-file import (CREATE DATABASE ... FROM 's3://...') when the source is already packaged in cloud storage
• target environment (databases, roles, shares, service accounts) defined in Terraform when it must be recreated across dev, staging, and production
• secure views on Shares when the legacy warehouse enforced row access policies, column masking, or secure views; map each policy and test it as the affected consumer
• capture validated business definitions, join rules, and cutover caveats in Guides after the target model stabilizes