You may use one configuration for multiple accounts. You may repair problems caused by human errors, incorrect manual interventions, unexpected bugs, system outages, etc.
Lack of option to revert changes is one of the biggest problems of imperative-style object management tools. It does not exist in SnowDDL.
New columns can be added and some data types can be changed instantly, without full table rewrite and at no extra cost.
GRANTS will no longer be a problem when organization complexity grows.
.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.
CREATE). "Safe" queries usually do not require code review and can be applied immediately.
DROP). "Unsafe queries" usually do require more attention.
You decide which DDL categories to "apply" immediately and which categories to "suggest" for manual review and manual application by
ACCOUNTADMINlater. SnowDDL will not accidentally DROP your database, unless you explicitly allow it to happen.
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.
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).
You may build custom automation based on any data source when basic configs are no longer enough.