Snowflake DCM Projects Is Now GA: What Changed Since Preview

※This is the English translation of the article : https://dev.classmethod.jp/articles/snowflake-dcm-projects-ga/

This is Sagara.

In March 2026, "DCM Projects" — a Snowflake-native way to declaratively manage Snowflake objects — was released as a Preview feature.

At that time, I ran a verification where I used Jinja templates to build DEV / PROD environments within the same Snowflake account.

https://dev.classmethod.jp/articles/snowflake-dcm-projects-preview/

Then, in the Snowflake release notes dated August 7, 2026, the General Availability (GA) of DCM Projects was announced.

https://docs.snowflake.com/en/release-notes/2026/other/2026-08-07-dcm-projects-ga

:::message
In this article, I mainly organize what has changed since the Preview announcement (as of March 20, 2026). Please note in advance that this article does not include any hands-on verification.
:::

In this article, I check the following:

• What changed with the GA of DCM Projects
• Which objects can be managed at this point
• Which features remain in Preview even after GA
• What still cannot be defined with DCM Projects, such as Storage Integration
• What constraints you should be aware of when using it

Note that the content of this article is based on the official documentation as of August 8, 2026 (JST).

About the GA of DCM Projects and the Preview status of related features

DCM Projects itself has reached GA.

Therefore, the core workflow — declarative management of Snowflake objects with DEFINE, absorbing environment differences with Jinja templates, reviewing changes with PLAN, and applying them with DEPLOY — is now easier to consider as an option for production use.

However, DCM Projects reaching GA is not the same as every syntax, object, and peripheral feature related to DCM Projects reaching GA.

In practice, Preview features still remain for things like data quality tests, GitHub Actions integration, Pipes and Streams, data protection policies, and attaching Tags.

So when deciding whether to adopt it, you need to check whether the specific objects and syntax you want to use are GA or Preview.

Status quick reference

Category	Status	Main contents
DCM Projects core features	GA	DEFINE, Jinja, PLAN, DEPLOY
Quality / pre-checks	Preview	TEST, PREVIEW
CI/CD integration	Preview	GitHub Actions for DCM Projects
Some pipeline definitions	Preview	DEFINE PIPE, DEFINE STREAM
Some governance features	Preview	DEFINE MASKING POLICY, DEFINE ROW ACCESS POLICY, ATTACH TAG
Advanced privilege management	Preview	Inherited Grants, container-level MANAGE GRANTS

TEST / PREVIEW, GitHub Actions, DEFINE PIPE, DEFINE STREAM, Masking Policy, Row Access Policy, ATTACH TAG, Inherited Grants, and container-level MANAGE GRANTS are still Preview as of August 8, 2026.

Reference: My verification article from the Preview period

When DCM Projects was in Preview, I wrote the following verification article.

https://dev.classmethod.jp/articles/snowflake-dcm-projects-preview/

In that article, I tried a configuration where DEV / PROD environments were deployed from a single DCM project folder.

• Defined DEV / PROD targets in manifest.yml
• Created a separate DCM project object for each environment
• Switched Database names and Warehouse sizes with Jinja templates
• Checked the changes with PLAN before running DEPLOY
• Managed Database, Schema, Warehouse, Role, Grant, Table, Dynamic Table, Task, and so on

This basic approach has not changed even now that DCM Projects has reached GA.

For that reason, this article does not re-verify that basic configuration, and instead focuses on "how far the supported scope has expanded" and "what still cannot be completed with DCM Projects alone."

Main changes since the Preview period

Diff list

Item	At the time of Preview verification	Now
DCM Projects itself	Preview	GA
Basic flow	DEFINE → PLAN → DEPLOY	Unchanged
Jinja templates	Supported	Unchanged
File Format	Introduced as unsupported	Supported
External Stage	Not verified	Supported
Sequence	Not covered	Supported
Share	Not covered	Supported
Network Rule / Policy	Not covered	Supported
Function / Procedure	Not covered	Supported
Alert	Not covered	Supported
PLAN DELTA	Not covered	Feature added
TEST ALL	Covered in the article	Still Preview

The most obvious difference from my previous article is that File Format is now supported.

By combining File Format, External Stage, Table, Task, and so on, you can now manage the Snowflake-side settings required for data loading in definition files in a more consistent way.

Network Rule / Network Policy and Share are also included in the supported scope.

I feel that DCM Projects is not merely a feature for creating Databases, Schemas, and Tables — it is expanding toward managing Snowflake environment foundation settings, data pipelines, sharing configurations, and even some governance settings as code.

Also, PLAN DELTA was added on July 16, 2026. It lets you quickly check only the definitions you changed and their downstream dependencies, which is convenient for iteration during development, but it is recommended to run a normal full PLAN before deploying to confirm the entire scope of impact.

List of what can currently be defined and managed with DCM Projects

In DCM Projects definition files, you can use the following three types of statements:

• Entity: define Snowflake objects with DEFINE statements
• Grant: define privileges and role hierarchies with GRANT statements
• Attachment: associate DMFs, Tags, and so on with targets using ATTACH statements

The following is a support list based on the official documentation as of August 8, 2026.

https://docs.snowflake.com/en/user-guide/dcm-projects/dcm-projects-supported-entities

Entity: objects you can DEFINE

Foundation / containers / compute

Object	Status	Notes
Database	GA
Schema	GA
Warehouse	GA
Role	GA	Account Role
Database Role	GA	Role scoped within a Database
Sequence	GA
Tag	GA	Tag definition. ATTACH TAG to Views or individual table columns is not supported
Share	GA	Shares and Grants to Shares can be managed

Data model / pipelines

Object	Status	Notes
Table	GA	Some column changes and Tag / Policy-related operations have constraints
View	GA	Constraints on changing column order
Dynamic Table	GA	Depending on the change, re-initialization or a full refresh is required. INITIALIZE cannot be changed
File Format	GA	A clear expansion since the Preview-era article
External Stage	GA
Internal Stage	GA
Task	GA	STARTED / SUSPENDED state management is possible
Alert	GA	STARTED / SUSPENDED state management is possible
Pipe	Preview	DEFINE PIPE. After creation, nothing but COMMENT can be changed
Stream	Preview	DEFINE STREAM. After creation, nothing but COMMENT can be changed

Functions/Procedures, policies, data quality

Object	Status	Notes
Function	GA	SQL / Java / JavaScript / Python / Scala
Procedure	GA	SQL / Java / JavaScript / Python / Scala
Data Metric Function	GA	User-defined DMFs can be defined with DEFINE DATA METRIC FUNCTION
Authentication Policy	GA	Policy definition
Network Rule	GA	TYPE / MODE cannot be changed after creation
Network Policy	GA	Assigning the policy is out of scope for DCM
Masking Policy	Preview	The policy definition itself is possible
Row Access Policy	Preview	The policy definition itself is possible

The official DCM Projects support list enumerates the above Entities as definable targets. Pipe, Stream, Masking Policy, and Row Access Policy are Preview. Also, since DEFINE statements are executed as CREATE OR ALTER for the corresponding Snowflake object, they inherit the constraints of each object's CREATE OR ALTER as-is.

Grant: privileges you can manage

Feature	Status	Notes
Normal GRANT	GA	Granting privileges and Roles
GRANT OWNERSHIP	GA	Be careful about the relationship with existing Grants
Inherited Grants	Preview	GRANT INHERITED. Requires ALTER ACCOUNT SET FEATURE_RBAC_INHERITED_GRANTS = 'ENABLED' to enable
Container-level MANAGE GRANTS	Preview	Delegating privilege management per Database / Schema. Enabled with the same parameter as above
CALLER grants	Not supported	Out of scope for now

Normal GRANT and GRANT OWNERSHIP are available as GA.

On the other hand, what DCM Projects manages are the Grants defined and deployed via DCM Projects.

Grants applied manually or by another tool coexist, and DCM Projects will not arbitrarily remove Grants it does not know about.

However, GRANT OWNERSHIP has additional constraints regarding existing Grants. Because DCM Projects cannot use COPY CURRENT GRANTS or REVOKE CURRENT GRANTS, if the target object has existing Grants, you must either define the necessary Grants (including the existing ones) in the same DCM project, or revoke them outside of DCM Projects beforehand. If you don't, PLAN or DEPLOY will fail.

Also, when using GRANT OWNERSHIP, you need to include the Role that ownership is transferred to within the DCM project owner's role hierarchy, so that the DCM project owner can still manage the target object in subsequent deploys. If the DCM project owner does not hold the destination Role, PLAN or DEPLOY will fail before making any changes, in order to prevent a lockout.

For details on this behavior, please also see the "OWNERSHIP grants" section of the official docs below.

https://docs.snowflake.com/en/en/user-guide/dcm-projects/dcm-projects-supported-entities#ownership-grants

Attachment: what you can associate

Feature	Status	Notes
ATTACH DATA METRIC FUNCTION	GA	Attach DMFs to Table / View / Dynamic Table. The target side needs a DATA_METRIC_SCHEDULE setting (TRIGGER_ON_CHANGES is not available for Views)
ATTACH TAG	Preview	Can be applied to Database, Schema, Table, Dynamic Table, Function, Procedure, Stage, Task, Role, Database Role, and Warehouse
ATTACH TAG to Views	Not supported	Views are excluded from Tag targets
ATTACH TAG to individual table columns	Not supported	Object level only
Attaching Masking Policies	Not supported	Applying to Table / View columns must be done outside DCM
Attaching Row Access Policies	Not supported	Applying to Tables / Views must be done outside DCM

This part requires a bit of care.

Tags can be defined with DEFINE TAG, but ATTACH TAG, which applies a Tag to an object such as a Table, is Preview. In addition, tagging Views, or individual columns of Tables / Views / Dynamic Tables, is not supported at this point.

Also, for Masking Policies and Row Access Policies, even though you can define the policies themselves, attaching them to target Tables or Views is not yet supported in DCM Projects.

In other words, "being able to create a policy" and "being able to actually apply a policy" have different support statuses.

ATTACH DATA METRIC FUNCTION is supported. ATTACH TAG is Preview, and attaching Masking Policies and Row Access Policies to target objects is not supported.

Representative objects that still cannot be defined with DCM Projects even after GA

DCM Projects has reached GA, but that does not mean you can manage every Snowflake object with DEFINE.

The official documentation enumerates the Entities, Grants, and Attachments that DCM Projects supports. Therefore, objects not included in that support list — such as the following — must be treated as out of scope for DCM Projects definitions as of August 8, 2026.

In particular, for objects related to authentication, account settings, Snowpark Container Services, and Native Apps, it seems best to design on the assumption that they will be complemented by separate SQL scripts, external IaC such as Terraform, or operational procedures.

The official DCM Projects documentation enumerates the currently supported Entities, Grants, and Attachments. The list below shows representative examples that are not included in that supported scope.

Representative unsupported objects

Category	Representative examples that cannot be defined with DCM Projects	Practical impact / how to complement
External storage integration	Storage Integration	Integrations referenced by External Stages must be created and managed separately
External service / notification integration	Notification Integration, API Integration, External Access Integration	Notifications, external API calls, and external network access must be managed outside DCM
Authentication / identity federation	Security Integration	Settings such as SSO, OAuth, and SCIM must be managed separately
User management	User	Roles can be managed with DCM, but the User lifecycle must be managed separately
Cost management	Resource Monitor	Credit usage limits and notifications must be managed with separate SQL or IaC
Some table types	External Table, Iceberg Table, Materialized View, Hybrid Table, Event Table	Must be considered separately from normal Tables managed with DEFINE TABLE
Snowpark Container Services	Compute Pool, Service, Image Repository	The container execution platform requires a deployment path separate from DCM
Snowflake Native Apps	Application, Application Package, Application Role	Application Role is explicitly documented as unsupported
Some privilege grants	CALLER grants	Not supported as a Grant type
Other account settings	Account-level settings such as Account Parameters	Consider management means outside DCM, such as ALTER ACCOUNT

Objects that can be defined with DCM Projects but also require settings outside DCM Projects

Many objects can now be defined with DCM Projects, but in actual operations there are also many objects that require settings outside DCM Projects as well, so I'll list them here for reference.

Target	What you can do with DCM Projects	What is needed outside DCM
External Stage	Stage definition	Creating the Storage Integration and configuring cloud-side permissions
Pipe	Pipe definition (Preview)	Cloud event notifications when AUTO_INGEST = TRUE
Network Policy	Policy definition	Assignment to Account / User / Security Integration
Share	Share and Grant definitions	Adding consumer accounts
Python / Java Function / Procedure	Function / Procedure definition	Uploading the files used in IMPORTS to a Stage
Masking Policy	Policy definition (Preview)	Attaching to Table / View columns
Row Access Policy	Policy definition (Preview)	Attaching to Tables / Views
Tag	Tag definition	ATTACH TAG is Preview, and targets are limited to the object level

Constraints and operational caveats to keep in mind even after GA

DEFINE is subject to the constraints of CREATE OR ALTER

DEFINE in DCM Projects is executed as CREATE OR ALTER for the corresponding Snowflake object.

Therefore, even for objects that are managed by DCM Projects, you cannot freely change every attribute.

In particular, Tables have constraints on the following changes and settings:

• Changing column order
• Incompatible column type changes
• Adding Search Optimization
• Adding Tags / Policies to a Table or column
• Defining virtual columns

Also, for Pipes and Streams, nothing other than COMMENT can be changed after creation. Note that if you want to change the configuration, you essentially need to recreate the object.

Tables have constraints on the changes and settings above, and DEFINE is subject to the limitations of the corresponding CREATE OR ALTER. For Pipes and Streams, everything except COMMENT is immutable after creation.

There are upper limits on project size

There are upper limits on DCM Projects project size.

• Up to 10,000 Entities, Grants, and Attachments per project
• Up to 10,000 files under /sources
• A 10 MB size limit each for the source file set and the rendered definition file set

If you try to manage a large environment all together in a single DCM project, you may hit these limits. It's good to keep this in mind as a factor when considering how to split projects.

DCM Projects project size limits are: a maximum of 10,000 total Entities, Grants, and Attachments; a maximum of 10,000 files under /sources; and a 10 MB size limit each for the source file set and the rendered definition file set.

Conclusion

Since Snowflake DCM Projects reached GA on August 7, 2026, I organized the differences from the Preview period.

While supported objects such as File Format, External Stage, Sequence, and Share have steadily expanded, I felt it's important to note that there are still things not included in the supported scope even after GA, such as Storage Integration and attaching policies.

In any case, it is the quickest and easiest feature for managing Snowflake resources with IaC, so there's no doubt it's a very convenient feature. Let's make good use of it!