Skip to main content
Terraform is an open-source infrastructure-as-code tool that lets you define and manage cloud resources through declarative configuration files. With the PlanetScale Terraform provider, you can manage PlanetScale databases, branches, credentials, backups, backup policies, dedicated PgBouncers, and Postgres parameters and extensions alongside the rest of your infrastructure.

Conceptual model

The PlanetScale Terraform provider is organized around a clear distinction between Vitess and Postgres resources and is focused on long-lived infrastructure objects.
  • There are separate resources for each database kind—Vitess or Postgres.
  • The provider maps cleanly onto PlanetScale’s public API while exposing Terraform-friendly fields and lifecycle behavior.
PlanetScale databases do not have a dedicated Terraform resource. Their lifecycle is managed implicitly through branch resources:
  • Applying a planetscale_postgres_branch or planetscale_vitess_branch creates 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.

Credential models

Vitess and Postgres use different terminology for database credentials:

Quick start

This complete example creates a Postgres branch with application credentials:
Run:

Available resources

The provider offers resources for the most common automation scenarios:
  • planetscale_postgres_branch
  • planetscale_postgres_branch_backup
  • planetscale_postgres_branch_role
  • planetscale_postgres_redacted_branch_role
  • planetscale_postgres_backup_policy
  • planetscale_postgres_bouncer
  • planetscale_vitess_branch
  • planetscale_vitess_branch_backup
  • planetscale_vitess_branch_password
  • planetscale_vitess_backup_policy

Data sources

The provider also offers data sources for reading existing resources:
  • planetscale_databases
  • planetscale_database_postgres
  • planetscale_database_vitess
  • planetscale_organization
  • planetscale_organizations
  • planetscale_postgres_backup_policies
  • planetscale_postgres_backup_policy
  • planetscale_postgres_bouncer
  • planetscale_postgres_bouncers
  • planetscale_postgres_branch
  • planetscale_postgres_branch_backup
  • planetscale_postgres_branch_backups
  • planetscale_postgres_branch_role
  • planetscale_postgres_branch_roles
  • planetscale_postgres_redacted_branch_role
  • planetscale_vitess_backup_policies
  • planetscale_vitess_backup_policy
  • planetscale_vitess_branch
  • planetscale_vitess_branch_backup
  • planetscale_vitess_branch_backups
  • planetscale_vitess_branch_password
  • planetscale_vitess_branch_passwords

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

Postgres branch and role

Immutable attributes: Changing region, parent_branch, major_version, backup_id, or restore_point will destroy and recreate the branch. Use lifecycle { prevent_destroy = true } to protect production branches from accidental replacement.

Backups and backup policies

Use backup policy resources to define automatic backup schedules. Use branch backup resources to create managed backups. Both Vitess and Postgres support backup policies and branch backups. Postgres branch backups also support the emergency option.
For Vitess databases, use planetscale_vitess_backup_policy and planetscale_vitess_branch_backup with the same scheduling and retention fields.

Dedicated PgBouncers (Postgres)

Use planetscale_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.
Changing name or target destroys and recreates the bouncer. Omitted parameters values are reset to their defaults.

Postgres parameters and extensions

Postgres branches support a parameters map for cluster settings, PgBouncer settings, Patroni settings, and supported extension settings. Parameters are nested by namespace: pgconf, pgbouncer, and patroni.
Omitted values are reset to their defaults.
Some Postgres parameter and extension changes require a restart. See Postgres parameters and Postgres extensions for details.

Retrieving connection details

After creating a role or password, use Terraform outputs to retrieve connection information:

Postgres

Vitess

The password (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:

Read-only role for reporting

Create a role with read-only access for analytics and reporting:

Short-lived CI/CD credentials

Create credentials that automatically expire for CI/CD pipelines:

Postgres role without a password in state

Use planetscale_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’s lifecycle block to prevent accidental destruction of critical resources:
You should enforce your own review and approval processes around Terraform 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.
  1. 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.
  2. 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/Postgres branches, roles, passwords, and other supported resources.
    • Run terraform init to download the v1 provider and initialize your working directory. This creates a new, independent state file.
  3. Import existing resources into v1.x state
    • For each resource that you want Terraform to manage going forward, run terraform import for 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).
  4. Cut over automation
    • After resources are imported and terraform plan shows no unexpected changes, switch your automation (CI pipelines, etc.) to apply the v1 project.
  5. 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.

Importing existing resources

Resources are imported using JSON-encoded identifiers:
You can find resource IDs in the PlanetScale dashboard URL or via the API.

Need help?

Get help from the PlanetScale Support team, or join our Discord community to see how others are using PlanetScale.