# Main features ### 1) SnowDDL is "stateless" Unlike [schemachange](https://github.com/Snowflake-Labs/schemachange) and [Terraform](https://github.com/chanzuckerberg/terraform-provider-snowflake), SnowDDL does not maintain any kind of "state". Instead, it reads current metadata from Snowflake account, compares it with desired configuration and generates DDL commands to apply changes. > *You may use one configuration for multiple accounts. You may repair problems caused by human errors, incorrect manual interventions, unexpected bugs, system outages, etc.* ### 2) SnowDDL can revert changes SnowDDL can revert object schema to any point in the past. You may simply checkout previous version of configuration from Git and apply it with SnowDDL. > *Lack of option to revert changes is one of the biggest problems of imperative-style object management tools. It does not exist in SnowDDL.* ### 3) SnowDDL supports ALTER COLUMN Most changes to Snowflake table structure require full re-creation of table and micro-partitions with data. For large tables it may incur significant additional costs. But some changes are possible with [ALTER TABLE ... ALTER COLUMN](https://docs.snowflake.com/en/sql-reference/sql/alter-table-column.html) statement, which executes instantly and costs nothing. SnowDDL detects if it is possible to use ALTER TABLE before suggesting costly CREATE OR REPLACE TABLE ... AS SELECT. > *New columns can be added and some data types can be changed instantly, without full table rewrite and at no extra cost.* ### 4) SnowDDL provides built-in "role hierarchy" model Snowflake documentation mentions benefits of [role hierarchy](https://docs.snowflake.com/en/user-guide/security-access-control-overview.html#roles), but it does not provide any real world examples. SnowDDL [offers](https://docs.snowddl.com/guides/role-hierarchy) a well thought 3-tier role hierarchy model. It is easy to understand, largely automated and requires minimal configuration. Also, it is crystal clear for security officers and external auditors. > *GRANTS will no longer be a problem when organization complexity grows.* ### 5) SnowDDL re-creates invalid views automatically Views may become invalid when underlying objects were changed. SnowDDL detects such views using a free `.describe()` call, and re-creates such views if necessary. > *You'll get less complaints from users about invalid views. There is no need to maintain a separate script to fix views.* ### 6) SnowDDL simplifies code review DDL queries are classified into ["safe" and "unsafe"](https://docs.snowddl.com/guides/other-guides/safe-unsafe) categories. "Safe" queries can be applied and reverted with little to no risk (e.g. `CREATE`). "Safe" queries usually do not require code review and can be applied immediately. "Unsafe" queries may potentially cause loss of data or security issues (e.g. `ALTER`, `DROP`). "Unsafe queries" usually do require more attention. This classification helps to manage code review process better, but it is optional. > *You decide which DDL categories to "apply" immediately and which categories to "suggest" for manual review and manual application by `ACCOUNTADMIN` later.*\ > \ > *SnowDDL will not accidentally DROP your database, unless you explicitly allow it to happen.* ### 7) SnowDDL supports creation of isolated "environments" for individual developers and CI/CD scripts Multiple independent versions of the same configuration can be applied to one Snowflake account using [env prefix](https://docs.snowddl.com/guides/other-guides/env-prefix). Unique prefix will be added to name of each account-level object, which allows multiple developers to work on the same code simultaneously without conflicts. It is also helpful for automated testing, when each set of tests will be executed in a separate "environment". > *For example, you have a production database called `BOOKINGS`. Alice can create her own dev copy called `ALICE__BOOKINGS`, and Bob can create his own dev copy called `BOB__BOOKINGS`. Alice and Bob will never clash during development. Such "environments" can be created and destroyed instantaneously* *at any time.* ### 8) SnowDDL strikes a good balance between dependency management overhead and parallelism Different object types are resolved sequentially. But objects of the same type are resolved [in parallel](https://docs.snowddl.com/guides/other-guides/dependency-management). It provides great performance for configurations with large number of objects, but it also simplifies dependency management. > *All views are created after all tables. All tables are created after all schemas. Only rare dependencies within the same object type should be maintained (e.g. view depends on another view).* ### 9) SnowDDL configuration can be generated dynamically in Python code When basic YAML files are no longer enough, you may build and modify configuration [programmatically](https://docs.snowddl.com/advanced/programmatic-config) by adding Python modules to your config. ### 10) SnowDDL can manage packages for Java and Python UDF scripts natively Recently, Snowflake introduced [Snowpark](https://docs.snowflake.com/en/developer-guide/snowpark/index.html) and [UDF functions](https://docs.snowflake.com/en/sql-reference/sql/create-function.html) written in Java, Scala, Python. Such functions may rely on external packages and libraries, which should be uploaded to internal stages. Changes in packages should be synchronised with changes in UDF function code, and SnowDDL can do it for you using special object type [`STAGE FILE`](https://docs.snowddl.com/basic/yaml-configs/stage-file). --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.snowddl.com/features.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.