Skip to main content

Snowflake Table Re-creation During Deployment

When a Snowflake deploy plan shows Replace Table, Create Table, or Drop Table stages, Coalesce is signaling that an object may be re-created or dropped, not only altered in place. Use this guide to read plan output, decide when re-creation is expected, prevent unintended structural changes, and recover if a deploy already ran.

Before You Begin​

You need:

  • Access to deploy an Environment and ability to view deployments.
  • Familiarity with the Node Types and Packages in your Project. Standard Base Node Types, Advanced Deploy, and Create or Alter Nodes behave differently.
  • For recovery steps, permission to redeploy a prior commit and use Snowflake Time Travel on affected tables.

How to Read the Deploy Plan​

Coalesce builds a deployment plan before it runs DDL in Snowflake. Inspect that plan every time you deploy to production or any Environment where table data, grants, or downstream streams matter.

Review Plan in the Deploy Wizard​

During deployment, the Review Plan step lists every Node that will change in the target Environment. For each Node, open View Details to see generated SQL and the ordered list of stages Coalesce will execute. For the full wizard walkthrough, including the Changes tab for metadata-only diffs on altered Nodes, see Deploy Using the Coalesce App.

Treat these stage names as re-creation signals:

  • Create Table - Coalesce creates a new table, often on first deploy to an Environment
  • Replace Table - Coalesce runs CREATE OR REPLACE TABLE on an existing table
  • Drop Table - Coalesce removes a table or an internal clone table as part of a multi-step alter or materialization change

These stage names usually mean Coalesce is altering in place while preserving data when Snowflake allows the change:

  • Clone Table
  • Rename Table | Alter Column | Delete Column | Add Column | Edit table description
  • Swap Cloned Table

Advanced Deploy Nodes can show Metadata Update stages, for example Metadata Update | Join, that record configuration changes in comments without running DDL. That is not re-creation. Confirm the stage list includes no Replace Table, Create Table, or Drop Table steps before you assume the deploy is metadata-only.

Individual Run Page, API, and CLI​

After deploy, you can review the same stage names on the Individual Run Page, in List Run Results API responses, or in CLI output when you add --out to a deploy command. Each stage includes the SQL Coalesce executed and any error message.

Phased deploy errors reference delete, alter, and add phases. A failure in the delete phase often involves Drop Table stages. Failures in the alter phase often involve clone and swap stages.

Disable Plan Caching While Troubleshooting​

If stages look stale or do not match recent Node edits, regenerate the plan with deployment plan caching turned off. See Caching Deployment Plan for how to disable caching in the Deploy Wizard or CLI. A full re-render ensures Coalesce evaluates current Node metadata before you deploy.

When Coalesce Alters Versus Re-Creates​

Coalesce prefers non-destructive changes for column-level edits on standard Snowflake Base Node Types (Work, Persistent Stage, Dimension, and Fact) when those Nodes are materialized as tables. Logical or configuration changes to the Node definition often trigger full table re-creation instead.

Use the table below to interpret the most common plan patterns for standard base table Nodes. Package-specific Node Types, such as incremental, deferred merge, dynamic tables, and Create or Alter Nodes, follow their own redeployment rules. Open the redeployment section for your Node Type in the Coalesce Marketplace when your Nodes use a specialized Package.

Your changeTypical deploy behaviorCommon stagesData in the table
Add, drop, or alter a column with a supported typeAlter with clone and swapClone Table, column alter stages, Swap Cloned TablePreserved
Rename the tableAlterRename Table, often with clone or swapPreserved
Edit table descriptionAlterEdit table descriptionPreserved
Change join, transformation, DISTINCT, GROUP BY, or ORDER BYRecreateReplace Table or Create TableCleared at deploy; reload on refresh
First deploy of the Node to the EnvironmentCreateCreate TableEmpty until refresh
Switch materialization: table, view, or transientDrop and createDrop Table then Create Table or Replace TableDepends on path; treat as re-creation
Change Storage Mapping or Storage LocationDrop at old location, create at newDrop Table at prior location, Create Table at new locationNot migrated automatically
Unsupported column type changeAlter attempt may failClone/swap alter stages, then errorUse copy-table workflow instead

Column-level changes on standard base Nodes use a clone, alter, and swap pattern so existing rows stay in place when Snowflake accepts the DDL.

Environment docs and re-creation

High-level Environment documentation describes column changes using ALTER instead of drop and create. That applies to column-only edits on standard table Nodes. Definition and configuration changes on those same Nodes still use CREATE OR REPLACE and show Replace Table in the plan. Both behaviors are expected.

Advanced Deploy Nodes​

Advanced Deploy uses the same clone and swap path for column-level changes. Many configuration edits, such as join, transformation, or DISTINCT changes, appear as Metadata Update stages with is and was comments instead of DDL.

Materialization switches, such as table to view or table to transient table, use explicit Drop Table and Create Table or Replace Table stages. See the redeployment section for your Node Type in Snowflake Base Node Types Advanced Deploy.

Create or Alter Package​

The Create or Alter Package uses Snowflake CREATE OR ALTER for many schema changes as a less destructive alternative on supported Node Types. Materialization type switches can still require drop and create. Review the Package redeployment documentation for your Node Type before you deploy breaking DDL to production.

Common Scenarios​

Plan Shows Replace Table After a Join or Transform Change​

You edited the Join or Transform tab on a Work, Dimension, or Fact table Node. The plan lists Replace Table.

This is expected. Coalesce re-creates the table because the materialized query changed. After deploy succeeds, run a refresh or schedule one to reload data. Downstream Snowflake streams on the table can become stale after CREATE OR REPLACE TABLE. Re-create or refresh those streams in Snowflake if your pipeline depends on them.

Plan Shows Create Table on First Deploy​

The Node has never been deployed to this Environment, or Coalesce treats the target location as new.

Create Table on first materialization is normal. The table exists after deploy but is empty until a refresh loads rows.

Migrating an Existing Snowflake Table Into Coalesce​

You pointed a Node at a table that already exists and holds data populated outside Coalesce. The plan shows Create Table instead of adoption.

Understanding Presync compares Coalesce metadata with Snowflake before deploy. When an object already exists with a matching structure at the expected Storage Location, Presync can adopt it instead of re-creating it. Check:

  • Database, schema, and table name match the Node Storage Location and naming
  • Column names and types match what Coalesce generated for the Node
  • The deploy role can see the existing object

A naming or location mismatch often looks like an unexpected Create Table even when the table already exists elsewhere in Snowflake.

Storage Mapping or Location Change​

You changed a Node Storage Location or updated Environment Storage Mappings so objects move to a different database or schema.

Coalesce treats objects at the old location as removed and objects at the new location as new. The plan can include Drop Table at the old location and Create Table at the new one. Coalesce does not automatically copy data between locations.

If objects at the old location were deleted manually before deploy, the Drop Table stage can fail because there is nothing to drop. Restore the old schema or object long enough for Coalesce to complete the drop step, or adjust mappings and metadata with your platform admin before you redeploy. See Storage Mapping Deployment Failures for related errors.

Package or Node Type Upgrade​

Upgrading a Package version or switching Node Types can change which edits trigger metadata stages versus DDL. After an upgrade, regenerate the deploy plan with caching disabled and compare stages to your prior successful deploy.

Open the redeployment documentation for the new Package version. Advanced Deploy in particular separates metadata-only updates from drop-and-re-create paths when materialization type changes.

Unsupported Data Type Change​

You changed a column to a type Snowflake cannot convert with ALTER COLUMN. The plan may show alter stages, but deploy fails during the alter step with a Snowflake compilation error.

Do not accept a simple drop-and-re-create when column order or Type 2 SCD history matters. Follow Data Type Changes in Snowflake for the copy-table migration workflow instead.

Impact of Table Re-Creation​

When Coalesce runs CREATE OR REPLACE TABLE or drops and re-creates a table, Snowflake replaces the table object. Plan for these side effects before you deploy.

  • Data - Rows in a re-created table are replaced by the new definition. Data returns after refresh for materialized Nodes, but any data loaded only outside Coalesce is gone unless you recover it separately.
  • Grants and privileges - Privileges do not always carry over on every DDL path the way they do with explicit COPY GRANTS. Review grants after re-creation if downstream roles need continued access.
  • Streams - Validate and refresh stream status in Snowflake after deploy when streams depend on the table.
  • Tags and comments - Object tags and column comments managed outside Coalesce can be lost on drop-and-re-create paths. Sync descriptions in Coalesce when you rely on column comments in Snowflake.

Snowflake retains dropped table data for Time Travel according to your account retention settings, even when Coalesce re-creates the object.

Prevent Unintended Re-Creation​

Follow these practices before you deploy structural changes to production Environments.

  1. Open Review Plan and inspect View Details for every Node you changed. Stop the deploy if you see unexpected Replace Table, Create Table, or Drop Table stages.
  2. Test the same commit in a lower Environment first. Compare stage names and SQL to what you expect from your Node edits.
  3. Disable deployment plan caching when stages do not reflect recent Workspace changes.
  4. For production schema evolution where re-creation is risky, evaluate the Create or Alter Package on supported Node Types.
  5. Before you change Storage Mappings, plan how objects at the old location will be dropped and whether you need to migrate data separately.
  6. When you onboard existing warehouse tables, verify names, locations, and column structures so Presync can adopt objects instead of creating new ones. See Understanding Presync.
Stop the deploy when impact is unclear

If you cannot explain why a Node shows Drop Table or Replace Table, do not deploy to production. Resolve the underlying Node, mapping, or Package change first, or deploy to a non-production Environment to validate the plan.

Recover After Re-Creation​

Roll Back Structures​

Redeploy the commit that was deployed immediately before the change you want to undo. Rollback a Deployment restores structures in Snowflake:

  • New tables or columns from the rolled-back deploy are dropped
  • Tables or columns dropped during that deploy are re-created
  • Column changes from that deploy are reverted with ALTER

Rollback does not restore row data inside re-created tables. Treat rollback as a structural undo, not a data restore.

Restore Data With Time Travel​

When rollback re-creates a table or column but you need the previous rows, use Snowflake Time Travel after rollback completes. The Rollback a Deployment guide links to Snowflake Time Travel documentation for point-in-time recovery.

For unsupported type changes where you already lost history, follow Data Type Changes in Snowflake instead of relying on a simple re-create path.

Tables Dropped Outside Coalesce​

If a managed table was missing before deploy, Coalesce may re-create it automatically. That behavior is related to Presync and metadata reconciliation, not the same as replacing a table because you changed a join. See Tables Dropped Outside of Coalesce for lifecycle guidance and how missing objects interact with deploy.

What's Next?​