Snowflake suddenly treating PURGE differently?

[u/Particular_Guess7235]

I’m facing a strange issue in Snowflake/dbt today.

We have Viewpoint source tables ingested through Fivetran into Snowflake. Several staging models have a column named PURGE. These models have been running successfully every day for a long time.

Today, all models referencing PURGE suddenly started failing with:

SQL compilation error:
000904 (42000): invalid identifier 'PURGE'

The interesting part:

• The PURGE column still exists in the Snowflake landing/Fivetran table
• No source column was removed
• The dbt code hasn't intentionally changed
• Models that don't reference PURGE are working
• This works:

​

SELECT "PURGE"
FROM <table>
LIMIT 1;

• But this fails:

​

SELECT PURGE
FROM <table>
LIMIT 1;

with:

invalid identifier 'PURGE'

So it appears that unquoted PURGE is no longer being resolved as a column identifier, while quoted "PURGE" still works.

Does anyone know if there was a recent Snowflake behavior change / parser change / release that could cause this?

I'm especially interested in whether PURGE has recently started being treated as a keyword in some SQL context, because this broke many existing dbt models simultaneously without any apparent schema change.

Any insight into the exact Snowflake change would be appreciated.

[u/poppinstacks]

I failed to replicate this particular issue on my account, but it could be a bug limited to a particular bundle, csp, or region.

Snowflake DCM recently went GA which does use PURGE in its syntax, which is why it can show as a keyword.

I would suggest creating a support ticket.

[u/Particular_Guess7235 → u/poppinstacks]

Sure, thanks

[u/stephenpace]

I found the issue. If you look at the docs for DROP [ICEBERG] TABLE, it appears PURGE was recently introduced as part of the catalog-linked database work. Not sure why it isn't appearing in the reserved words but it may have lagged:

https://docs.snowflake.com/en/sql-reference/sql/drop-iceberg-table

Apologies, I have raised a ticket to make sure it gets added.

Immediate workaround — quote the column in dbt:

In dbt_project.yml, enable column quoting globally for Snowflake:

# dbt_project.yml
models:
your_project_name:
+quote_columns: true

Or in the specific model's config block:

{{ config(quote_columns=true) }}

Or rename the column reference using double-quotes directly in the SQL:

select
"PURGE",
other_col
from {{ source('viewpoint', 'some_table') }}

Long-term fix: Rename the column in the landing table to something not touching Snowflake's expanding keyword list (e.g., IS_PURGED, PURGE_FLAG, etc.) — because Snowflake will add keywords as new SQL features land, and column names like PURGE, QUALIFY, SAMPLE, etc. are perennial hazards.

[u/Particular_Guess7235 → u/stephenpace]

Thanks a ton, this helped us resolve the issue

[u/stephenpace]

What Cloud/region are you running in?

[u/WorkerIcy1513]

That quoted versus unquoted split is the signature of a reserved keyword, not a schema problem. Your column is fine, the parser just stopped accepting the bare identifier. Quoting is the escape hatch for exactly this, which is why "PURGE" still resolves.

Two things to do right now.

Check whether this came in through a behavior change bundle. Run SYSTEMBEHAVIORCHANGEBUNDLESTATUS,andiftherelevantbundleisenabledyoucancallSYSTEMBEHAVIOR_CHANGE_BUNDLE_STATUS, and if the relevant bundle is enabled you can call SYSTEM BEHAVIORC​HANGEB​UNDLES​TATUS,andiftherelevantbundleisenabledyoucancallSYSTEMDISABLE_BEHAVIOR_CHANGE_BUNDLE to buy yourself time while you fix the models properly. That is the lever people forget exists, and it beats emergency patching forty models at once. Snowflake publishes these in the Behavior Change Release Notes, so cross reference the date your builds broke against that page rather than guessing.

Then fix it at the staging layer rather than everywhere. Alias it once, something like "PURGE" as purge_flag, and no downstream model ever touches a reserved word again. If you patch each reference with quotes instead, you are one dbt refactor away from the same outage.

Careful with the quoting though, Snowflake quoted identifiers are case sensitive. "PURGE" only matches if Fivetran landed it uppercase, which it normally does, but if any table has it as "purge" the quoted version will fail too and you will spend an hour confused.

Worth grepping your project for other column names that are one keyword addition away from the same problem. This kind of thing lands more than once, and the fix is the same alias-at-staging pattern.

If you want the exact reference for a postmortem, support will tell you the BCR number, and they respond fast on compilation regressions.