Relational to Snowflake
Warehouse types are a review, not a surprise
Snowflake is drafted with the types the warehouse actually uses, and you read that draft before anything runs. Snowflake enforces only NOT NULL and has no indexes, so constraints your operational database relies on will not be enforced once the data lands there. Plan the move as a load with a cutover window, and review the draft schema first.
Reality check
What is automated
| Aspect | Status on this path |
|---|---|
| Source engines | PostgreSQL, MySQL, SQL Server, Oracle, MongoDB, or Snowflake itself the six Conversion Studio keys. |
| Target generation | Dedicated Snowflake draft and schema generators. Types go through a Snowflake dialect over the PostgreSQL generator. |
| Type mapping | Engine-specific, not the test-covered relational matrix. Review generated types before cutover. |
| CDC | Not available. This is a one-time full load with progress, rejected samples, and per-entity validation. |
| Protecting a destructive change | A warehouse is a reporting copy, not the system of record. Keep the source of truth on the operational database, where destructive work is preserved before it runs. |
| Warehouse to warehouse | Warehouses enforce almost no constraints and have no indexes, so moving between them is a modelling conversation rather than a like-for-like copy. Bring us the pair and we will map it with you. |
After the load
Operate Snowflake in the same product
Explorer, same-engine compare, governed scripts, and the audit ledger apply once the data is in Snowflake. Drift snapshots can watch the warehouse schema against a baseline. Compare still will not diff Snowflake against PostgreSQL as a structural merge.