// the take
The official Databricks Terraform provider, maintained by Databricks itself, for provisioning and managing workspaces, clusters, Unity Catalog, jobs, apps, and access control across AWS, Azure, and GCP. It's for platform and infra teams who want Databricks managed as code rather than through the UI or notebooks.
Resource coverage is enormous and basically 1:1 with the Databricks REST API — clusters, Unity Catalog, jobs, dashboards, apps, account-level IAM, you name it. CI is serious: build, integration tests against live workspaces, CodeQL, schema validation, and a dependabot feed, which matters for a provider this large. It ships an exporter that reverse-engineers an existing workspace into Terraform config, which is the realistic way most teams actually adopt this (backfilling IaC for stuff already clicked into existence). One provider handles all three clouds instead of forcing you to juggle cloud-specific variants.
The exporter — the thing most people reach for first when migrating an existing workspace — is explicitly labeled experimental with an interface that can change or disappear between versions. The API surface moves fast (commits land almost daily), so breaking changes between minor versions happen and pinning + reading the changelog isn't optional. Newer areas like agent_kit and ai_gateway resources are thin wrappers over Databricks APIs that are themselves still shifting, so expect rougher edges and sparser docs there than in the long-stable cluster/catalog resources. Unity Catalog permission and workspace-binding resources are known to drift and fight with changes made outside Terraform (UI, notebooks, other automation), which is a real operational tax once a team isn't 100% IaC-disciplined.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →