Conceptual model
The PlanetScale Terraform provider is organized around a clear distinction between Vitess, Neki, and Postgres resources and is focused on long-lived infrastructure objects.- There are separate resources for each database kind—Vitess, Neki, or Postgres.
- The provider maps cleanly onto PlanetScale’s public API while exposing Terraform-friendly fields and lifecycle behavior.
- Applying a
planetscale_vitess_branch,planetscale_neki_branch, orplanetscale_postgres_branchcreates the parent database if it does not already exist. - Destroying the last branch in a database also destroys the database. See Deletion protection for safeguards.
planetscale_neki_configuration_profile or planetscale_neki_shard. Creating a Vitess branch likewise provisions the branch’s default keyspace; import it to manage its size or replicas.
Credential models
Vitess, Neki, and Postgres use different terminology for database credentials:Quick start
This complete example creates a Postgres branch with application credentials. Vitess and Neki follow the same pattern with their own branch and credential resources.Available resources
The provider offers resources for the most common automation scenarios: Vitessplanetscale_vitess_backup_policyplanetscale_vitess_branchplanetscale_vitess_branch_backupplanetscale_vitess_branch_passwordplanetscale_vitess_keyspace
planetscale_neki_adminplanetscale_neki_backup_policyplanetscale_neki_branchplanetscale_neki_configuration_profileplanetscale_neki_roleplanetscale_neki_routerplanetscale_neki_shardplanetscale_neki_sidecar
planetscale_postgres_backup_policyplanetscale_postgres_bouncerplanetscale_postgres_branchplanetscale_postgres_branch_backupplanetscale_postgres_branch_roleplanetscale_postgres_read_only_replicaplanetscale_postgres_redacted_branch_role
Data sources
The provider also offers data sources for reading existing resources: Organization and databasesplanetscale_databasesplanetscale_database_postgresplanetscale_database_vitessplanetscale_organizationplanetscale_organizations
planetscale_vitess_backup_policiesplanetscale_vitess_backup_policyplanetscale_vitess_branchplanetscale_vitess_branch_backupplanetscale_vitess_branch_backupsplanetscale_vitess_branch_passwordplanetscale_vitess_branch_passwordsplanetscale_vitess_keyspaceplanetscale_vitess_keyspaces
planetscale_neki_adminplanetscale_neki_backup_policiesplanetscale_neki_backup_policyplanetscale_neki_branchplanetscale_neki_configuration_profileplanetscale_neki_configuration_profilesplanetscale_neki_roleplanetscale_neki_rolesplanetscale_neki_routerplanetscale_neki_routersplanetscale_neki_shardplanetscale_neki_shardsplanetscale_neki_sidecar
planetscale_postgres_backup_policiesplanetscale_postgres_backup_policyplanetscale_postgres_bouncerplanetscale_postgres_bouncersplanetscale_postgres_branchplanetscale_postgres_branch_backupplanetscale_postgres_branch_backupsplanetscale_postgres_branch_roleplanetscale_postgres_branch_rolesplanetscale_postgres_read_only_replicaplanetscale_postgres_read_only_replicasplanetscale_postgres_redacted_branch_role
Data source behavior
Refer to the Terraform Registry and provider documentation for the full, up-to-date list of available resources and data sources.
Provider configuration
The provider supports authentication using service tokens. Example configuration:Example usage
Vitess branch and password
Vitess keyspace
Creating aplanetscale_vitess_branch already provisions the branch’s default keyspace. Use planetscale_vitess_keyspace for additional keyspaces, or import the default keyspace to manage its size or replicas. cluster_size and extra_replicas update in place. Changing planetscale_vitess_branch.cluster_size still replaces the branch.
Neki branch and role
Neki routers and cluster configuration
Creating a Neki branch already provisions a default configuration profile, shard, router group, admin, and sidecar. Import those objects if Terraform should manage their size or parameters. Useplanetscale_neki_configuration_profile, planetscale_neki_shard, and planetscale_neki_router to add more.
Clients connect through an additional router group by appending the group name to the username, e.g. user|analytics. See Connect to Neki.
Postgres branch and role
Backups and backup policies
Use backup policy resources to define automatic backup schedules. Use branch backup resources to create managed backups. Vitess, Neki, and Postgres support backup policies. Vitess and Postgres also support branch backup resources. Postgres branch backups also support theemergency option.
planetscale_vitess_backup_policy and planetscale_vitess_branch_backup with the same scheduling and retention fields. For Neki databases, use planetscale_neki_backup_policy with the same scheduling and retention fields.
Dedicated PgBouncers (Postgres)
Useplanetscale_postgres_bouncer to manage a dedicated PgBouncer for a Postgres branch. Clients connect through it by appending the bouncer name to the username, e.g. postgres.abc123|my-bouncer.
Postgres read-only replicas
Useplanetscale_postgres_read_only_replica to add a read-only replica in the same region as the primary or in a different region. The replica can use a different cluster size than the primary.
Postgres parameters and extensions
Postgres branches support aparameters map for cluster settings, PgBouncer settings, Patroni settings, and supported extension settings. Parameters are nested by namespace: pgconf, pgbouncer, and patroni.
Retrieving connection details
After creating a role or password, use Terraform outputs to retrieve connection information:Vitess
Neki
postgres logical database by default. See Connect to Neki.
Postgres
The
password (Neki and Postgres) and plain_text (Vitess) fields are only available after the initial terraform apply. They are marked as sensitive and stored in Terraform state. To manage a Postgres role without storing its password in state, use planetscale_postgres_redacted_branch_role instead.Practical examples
Development branch workflow
Create a development branch forked from your main branch. Optionally specify a larger cluster size if you need more resources than the default. Neki development branches start empty and do not copy the parent branch’s schema or data; restore a backup when you need existing data.Read-only role for reporting
Create a role with read-only access for analytics and reporting. Neki uses the sameinherited_roles pattern with planetscale_neki_role:
Short-lived CI/CD credentials
Create credentials that automatically expire for CI/CD pipelines:Postgres role without a password in state
Useplanetscale_postgres_redacted_branch_role when Terraform should manage the role but the password should live in your secret manager instead of Terraform state. After creating the role, reset its password through the reset role API and store the new credential in your secret manager.
Configuration reference
Deletion protection
Branch deletion is one of the most sensitive operations in infrastructure automation. To reduce risk, use Terraform’slifecycle block to prevent accidental destruction of critical resources. Neki branches also support a native deletion_protected attribute:
apply, particularly for changes that delete or recreate branches.
Upgrading from v0.x to v1.x
The original PlanetScale Terraform provider was not officially supported for production use and is no longer maintained. Because the new v1 provider is a breaking rewrite, migration from v0.x to v1.x is a one-time, manual transition. Projects using the v0 provider will continue to work as normal, but this version will not receive further updates.- Pin v0.x in existing workloads
- Ensure all existing Terraform projects using the PlanetScale provider are pinned to
~> 0.6.1(or a specific v0.x version) to avoid unintentional upgrades.
- Ensure all existing Terraform projects using the PlanetScale provider are pinned to
- Create a new Terraform project for v1.x
- Create a separate directory with a new configuration using the v1 provider.
- Use the v1 resource types for Vitess, Neki, and Postgres branches, roles, passwords, and other supported resources.
- Run
terraform initto download the v1 provider and initialize your working directory. This creates a new, independent state file.
- Import existing resources into v1.x state
- For each resource that you want Terraform to manage going forward, run
terraform importfor the corresponding v1 resource. - Expect import to use IDs that align with the v1 API design (for example, IDs rather than purely name-based identifiers).
- For each resource that you want Terraform to manage going forward, run
- Cut over automation
- After resources are imported and
terraform planshows no unexpected changes, switch your automation (CI pipelines, etc.) to apply the v1 project.
- After resources are imported and
- Sunset v0.x usage
- Once you have validated v1.x in production, retire the v0.x configurations and keep them only for historical reference, if needed.

