motherduck-migrate-to-motherduck

Classify the workload, pick a target pattern (native MotherDuck storage by default), move data in bulk via Parquet or object storage, rebuild the analytical model in DuckDB SQL, then validate and cut over one workload at a time with rollback checkpoints.

Use pg_duckdb when extending an existing PostgreSQL estate is the least disruptive path, keeping OLTP in PostgreSQL while offloading analytics. Use native MotherDuck storage for cleaner warehouse-style landings and simpler managed operation.

Run source-vs-target checks comparing row counts, SUM/AVG/MIN/MAX metrics with percent variance, uniqueness, and new/deleted/changed records via EXCEPT queries or row hashing. The included Python orchestrator runs all checks and reports pass/fail against a variance threshold.

No. The PG endpoint still runs DuckDB SQL, not PostgreSQL SQL. PostgreSQL-specific syntax, temp-table habits, local-file imports, and extension management will not survive unchanged over the PG endpoint.

Use DuckLake only when open-table-format interoperability, bring-your-own-bucket storage ownership, or migration from Iceberg-oriented lake workflows is an explicit requirement. Native MotherDuck storage is simpler and often materially faster for normal analytical reads.