Skip to main content

Do I need to plan/approve for every database when applying to multiple databases?

When I have the same schema deployed across multiple database servers, do I need to plan and approve migrations for each database separately?

Answer​

No, you don't need to plan/approve for every database server if they all share the same schema state.

Atlas matches migration plans by schema state transition, not by database URL. When you run atlas schema apply, Atlas:

  1. Computes a fingerprint of the current database state (S1) and the desired state (S2)
  2. Checks the Atlas Registry for an approved plan matching this transition (S1 → S2)
  3. If a pre-approved plan is found, applies it without requiring additional approval

If all your databases are in the same state, a single approved plan works for all of them.

What if databases have diverged?​

If a database is in a different state (due to manual changes or partial failures) and no pre-approved plan exists, Atlas computes the migration to transition the database from S1 to S2, runs analysis (linting) on the plan, and handles it based on your Review Policy configuration:

  • ERROR - Auto-approve if no lint errors; otherwise, wait for approval
  • WARNING - Auto-approve if no warnings/errors; otherwise, wait for approval
  • ALWAYS - Always wait for approval

When auto-approval doesn't pass and no pre-approved plan exists, Atlas can use ad-hoc approvals: it automatically creates a plan, provides you a link to review it in Atlas Registry, and waits for your approval before continuing. This ensures no unexpected changes are applied without explicit review.

Learn how to set up ad-hoc approvals for your CI/CD pipeline:

GitHub Actions Ad-hoc Approval

Set up ad-hoc approvals in GitHub Actions workflows

Kubernetes Ad-hoc Approval

Set up ad-hoc approvals with the Atlas Kubernetes Operator

The screenshot below shows an ad-hoc plan in the Atlas Registry:

Ad-hoc plan approval in Atlas Registry