The Snowflake Terraform provider is SQL with a plan attached

The provider works by issuing Snowflake SQL

The scope is stated in one line: the Snowflake provider for Terraform manages Snowflake objects, meaning databases, warehouses, users, roles, grants and more, through Snowflake SQL. That last clause is the whole design in three words. There is no separate control plane API being wrapped and no declarative spec being translated. A resource maps to SQL that Snowflake executes, and Terraform's job is to work out whether that SQL needs to run. The consequence for an adopter is that the provider's behaviour is Snowflake's behaviour. If a grant syntax is accepted by Snowflake, the provider can usually express it, and if Snowflake changes how a statement is parsed, the provider has to follow. The repository reflects that, with a go.mod that pulls in the gosnowflake driver at v2.3.0 alongside both the Terraform plugin framework at v1.19.0 and the older plugin SDK v2 at v2.40.1, plus the plugin mux, which is what lets a provider serve resources implemented against either generation.

Preview resources are off by default and can change without a major bump

The support policy is unusually well signposted, and it is the first thing to read. The provider is generally available, but some resources and data sources are still preview: they are disabled by default, they may change without a major version bump, and they are not officially supported. You enable them with preview_features_enabled in the provider configuration, and the registry docs carry separate lists of currently preview resources and currently preview data sources. A second flag, experimental_features_enabled, changes the behaviour of existing resources, and it is also a preview feature. That distinction matters in practice. A preview resource that you opt into can change under you, but an experimental flag changes the behaviour of resources you already rely on, so the second is the riskier of the two even though both live behind the same preview banner. If you are pinning provider versions in a shared configuration, the flag set is part of that pin.

The supported surface starts at Terraform 1.1.5 and provider 2.0.0

Requirements are stated precisely. The Terraform CLI must be 1.1.5 or later, with a known issues page covering old Terraform CLI versions. For official support of stable resources the provider must be v2.0.0 or later, and the recommendation is to prefer the latest 2.x release. You also need a Snowflake account and a user or role that can create the objects you want to manage, and the introductory tutorial on the Snowflake guides site shows how to set up a service user and role. One exclusion stands out: OpenTofu is not supported. The provider is listed in the OpenTofu Registry, but compatibility is untested, and the FAQ carries a dedicated section on the question. The support boundary is drawn just as sharply. Official support starts with v2.0.0 for stable resources and data sources only, and all previous versions, preview resources and data sources, and experimental behaviours are not officially supported. The repository is not archived, the last push was on 2026-10-20, and recent releases are v2.22.0 on 2026-10-13, v2.21.0 on 2026-09-10 and v2.20.0 on 2026-08-21, so the 2.x line is where work is happening.

Key-pair authentication with a private key file, not a password

The example configuration uses key-pair JWT authentication, and the documentation is direct that this is only one of the supported methods, with a guide listing the others. The provider block takes an organization name, an account name, a user, an authenticator set to SNOWFLAKE_JWT, a private key read from a file, and a role. The private key is read with the file() function, which is the point to notice, because the documentation instructs you to keep keys and other secrets out of version control, and to use file(), environment variables, or a ~/.snowflake/config profile instead. The example pins a role of SYSADMIN, which is the broadest role in a Snowflake account and a poor default for a production service user. The full provider block as published looks like this:

provider "snowflake" {
  organization_name = "<organization_name>"
  account_name      = "<account_name>"
  user              = "<user_name>"
  authenticator     = "SNOWFLAKE_JWT"
  private_key       = file("~/.ssh/snowflake_key.p8")
  role              = "SYSADMIN"
}

The introductory tutorial exists because of exactly this, showing how to set up a service user and role with narrower grants. A Terraform provider that writes SQL will happily act with whatever privileges the configured user holds, so the credential you give it defines the blast radius of a bad plan.

Three commands take you from an empty directory to a created database

The getting started path is short enough to describe completely. A required_providers block pins the source to snowflakedb/snowflake and the version to a ~> 2.20 constraint, and the provider block above it carries the connection details. The resource that follows creates a single database named TF_DEMO, and the whole configuration is short enough to read in one screen. Then the three standard Terraform commands do the work:

terraform init   # download the provider
terraform plan   # preview changes
terraform apply  # create the resources

Read the plan output carefully, because with a SQL backed provider the diff shows the statements that will run rather than a structural change, and a grant that looks small in a diff can be wide in practice. The registry source is snowflakedb/snowflake, and the full resource and data source reference lives in the registry documentation. The provider also ships a set of examples in the repository under examples/, split into resources, data-sources, provider and additional directories, which is the fastest way to see the shape of a configuration for each object type before writing your own.

Official binaries cover a narrow architecture set, and the rest is best effort

The supported architecture list follows what the gosnowflake driver supports and what HashiCorp recommends for Terraform providers, and the official set is short. Windows is supported on amd64. Linux is supported on amd64 and arm64. Darwin is supported on amd64 and arm64. A second tier of binaries is published but not officially supported, meaning fixes are not prioritised: Windows arm64 and 386, Linux 386, Darwin 386, and FreeBSD on any architecture. If you run the provider in CI on a container image with an unusual base, that second tier is a real risk rather than a footnote. The build itself is driven by goreleaser, with a .goreleaser.yml in the tree, and the Makefile sets up a local plugin directory under the home terraform plugin path so a developer build can be tested against a real account. The same Makefile wires up the tooling: golangci-lint at a pinned version, tfplugindocs for generating the registry documentation, and gofumpt for formatting.

The repository carries four separate migration documents

The set of documents at the top of the repository tells you how much the resource surface has moved. There is a MIGRATION_GUIDE.md, a SNOWFLAKE_BCR_MIGRATION_GUIDE.md for the behaviour change release migration, a CZI_UPGRADE.md, and a SNOWFLAKEDB_MIGRATION.md, alongside a FAQ.md, a KNOWN_ISSUES.md, a ROADMAP.md, a CHANGELOG.md and a CREATING_ISSUES.md. Four migration guides for a provider in the 2.x series is a signal that resource names and schemas have changed more than once, and the go.mod module path still reads github.com/Snowflake-Labs/terraform-provider-snowflake even though the repository and the registry namespace are snowflakedb. That is a small but genuine trip hazard for anyone writing automation that clones or references the module path, and it is the kind of inconsistency that a search for the provider name will surface. There is also a v1-preparations/ directory in the tree, a legal file, and a .snyk file for vulnerability scanning of dependencies.

Where the Snowflake provider is the wrong tool

Three situations argue against it. The first is an account full of objects that were created outside Terraform and never imported. A Terraform provider has no way to know the current state of a database or a role unless that state is either declared in the configuration or brought in through an import step, and the documentation does not describe a bulk adoption path. Applying a configuration on top of unknown state can produce a plan that tries to recreate things that already exist. The second is a team that wants Snowflake to be self-service for analysts. The provider is a way to apply SQL from a reviewed plan, which is the opposite of granting analysts a UI or a notebook to experiment in. The third is the preview surface itself. If your requirements include a resource that is still preview, then you are accepting that it may change without a major version bump and that official support does not cover it, which is a poor foundation for a production data platform. A reasonable alternative for the same goal is driving the same SQL through a different execution path, for example a migration tool run inside your release pipeline, which gives you the same declarative SQL without a Terraform state file to reconcile, at the cost of losing the plan and the drift detection that Terraform gives you in exchange.

Editorial conclusion

Adopt the Snowflake Terraform provider when your Snowflake objects are meant to be created and reviewed as code, and start with the tutorial and a single database resource before adding grants. Skip it if the objects in your account predate it and were never imported, since the provider has no way to know their state. Verify first that your Terraform CLI is 1.1.5 or later and that you are on a 2.x release, then read the migration guide and the BCR migration guide before upgrading, because the provider has moved its resource set more than once.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. snowflakedb/terraform-provider-snowflake on GitHub