Error: Non-Nullable Column Cannot Be Added to Non-Empty Table

Issue

Queries on Snowflake Iceberg tables fail, and the Snowflake Iceberg table's auto-refresh permanently stops, with an error similar to the following:

SQL compilation error: Non-nullable column '<column_name>' cannot be added to
non-empty table '<table_name>' unless it has a non-null default value.

You may also see the table's refresh status stuck as follows:

SELECT SYSTEM$AUTO_REFRESH_STATUS('<database>.<schema>.<table_name>');

{
  "invalidExecutionStateReason": "SQL compilation error: Non-nullable column '<column_name>' cannot be added to non-empty table '<table_name>' unless it has a non-null default value...",
  "executionState": "GENERALIZED_PIPE_STOPPED"
}

This error can occur whenever a schema migration adds a new required (non-nullable) column to a table that already has synced rows. Fox example:

• Enabling History Mode on a table, which adds the required _fivetran_start column.
• Adding or changing a table's primary key, which can introduce new required key columns.
• Any other schema migration that introduces a new required column on an existing, non-empty table.

Environment

• Destination: Managed Data Lake Service
• Query engine: Snowflake
• Table format: Apache Iceberg (v2)

Cause

When a schema migration adds a new required column to a table (for example, _fivetran_start when History Mode is enabled, or a new key column when a primary key changes), the column is written as non-nullable. Iceberg table format v2 has no way to specify an initial default value for a newly added non-nullable column.

For a non-empty table, Snowflake expects a default value to be available for the new non-nullable column. However, Fivetran writes Iceberg tables in v2 format, and the concept of a column default value was only introduced in Iceberg v3. Snowflake enforces this default-value requirement even on v2 tables, which is a limitation of Snowflake.

Once a table's refresh is blocked, it keeps failing on every subsequent refresh attempt until the table is recreated. Fivetran's own catalog is not affected because it does not enforce this same constraint, so syncs continue to write to the underlying tables successfully — only the Snowflake-linked view of the table is impacted.

Resolution

Because the affected Iceberg table's metadata is stuck in a state Snowflake cannot repair or refresh in place, you must force Snowflake to rediscover the table from Fivetran's remote catalog, which is unaffected by this issue.

To resolve this, block and then unblock the affected namespace:

1. Block the affected namespace so Snowflake drops its registration of it:

   ALTER DATABASE <database_name> UPDATE LINKED_CATALOG
     ADD ('<namespace_name>') TO BLOCKED_NAMESPACES;
   

2. Unblock the namespace so Snowflake re-registers it and recreates its tables from the remote catalog on the next sync:

   ALTER DATABASE <database_name> UPDATE LINKED_CATALOG
     REMOVE ('<namespace_name>') FROM BLOCKED_NAMESPACES;
   

3. Confirm the table's refresh status is no longer stuck:

   SELECT SYSTEM$AUTO_REFRESH_STATUS('<database>.<schema>.<table_name>');
   

Only the blocked namespace is unavailable while this runs — other namespaces and Fivetran's remote catalog itself remain untouched.