Quartz 4

Atlas (Schema as Code)

3 min read

Core Principle

Atlas is a database schema management tool that brings Terraform-style declarative workflows to relational schemas. You write the desired schema as HCL or SQL DDL, Atlas diffs it against the live database (or a tracked desired-state), and generates a migration plan for review. It also supports a versioned-migration mode, so the same tool authors and applies migration files.

Why This Matters

Schema is special: it has ordering constraints across time, contains user data that must survive transformations, and interacts with running app code on its own deploy cadence. Generic Terraform providers can’t safely manage it because Terraform’s destroy-and-recreate semantics are lethal for tables with rows.

Atlas’s contribution is bringing the plan/diff experience to schema without losing the migration history and safety linting features that schema changes need. A column rename should generate ALTER COLUMN RENAME, not DROP + ADD. A table rewrite on a 100M-row table should produce a warning. A destructive change should require an explicit override. None of those checks exist in a Terraform provider.

Evidence/Examples

  • Declarative mode: write schema.hcl describing tables, columns, indexes. atlas schema apply plans and runs the diff.
  • Versioned mode: atlas migrate diff generates a versioned migration file from a schema change. You review, edit, commit, and atlas migrate apply runs forward.
  • Migration linting catches destructive changes, backward-incompatible changes, and lock-heavy operations on large tables, integrated into CI against a shadow database.
  • Terraform provider lets you wire Atlas into a Terraform pipeline if your infra workflow is already Terraform-shaped, without putting the schema directly into Terraform state.

Implications

  • Atlas is the right tool when you want declarative schema and the safety net of generated-but-reviewable migration files. It is not trying to replace Flyway or Liquibase for teams that want to hand-write every migration.
  • The mental model is: Terraform for API objects, Atlas for schema, app migration tool for schema + reference data tightly coupled to app code. See Infrastructure as Code for the full layering.
  • “Generated diffs” is the part to be skeptical about. Trust them in CI, never auto-apply to production without review. The lint pass is doing real work.
  • ORM-native migration tools (Alembic, Prisma Migrate, Django, Rails, Ecto) win when the schema lives next to the model definitions in app code. Atlas wins when schema is a first-class artifact owned by infra/platform, decoupled from one app’s framework.
  • Terraform — analogous declarative workflow at the infrastructure layer
  • Infrastructure as Code — the layering Atlas slots into
  • Ansible — procedural counterpart for machine config, similarly not the right tool for schema

Questions

  • How much of the lint catalog can be trusted on Postgres vs MySQL vs SQLite? Coverage is uneven across engines.
  • For teams already on Flyway with thousands of migrations, is the migration to Atlas worth the disruption, or is the right move to adopt Atlas only for new services?
  • How does Atlas handle multi-region or multi-tenant schemas where “the live database” is actually N databases with potential drift between them?

Graph View

Backlinks