testland/atlas-migrations

Authors and runs Atlas database schema migrations - declarative HCL or SQL schema definition with `atlas schema apply` for desired-state apply OR `atlas migrate diff` to generate versioned migrations against a dev DB; `atlas migrate apply` to deploy; `atlas migrate lint` to flag destructive / locking / data-loss patterns; `atlas migrate hash` to detect tampering. Supports PostgreSQL, MySQL, SQL Server, ClickHouse, SQLite, MariaDB, Snowflake, Oracle, Redshift, Spanner, CockroachDB, Databricks. Use when the user wants Terraform-style declarative DB schema management or modern SQL-first migration linting beyond Flyway / Liquibase.

Quality

86%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

HCL schema definition (Atlas DSL)

Atlas accepts the desired schema as SQL (most common) or as HCL, Atlas's own schema DSL. Both are desired-state inputs to the same atlas schema apply and atlas migrate diff commands (Steps 3-4), passed via --to file://<schema-file>.

HCL example

The users table from Step 2's SQL example, expressed in HCL:

table "users" {
  schema = schema.public
  column "id" {
    null = false
    type = serial
  }
  column "email" {
    null = false
    type = varchar(255)
  }
  primary_key { columns = [column.id] }
  index "unique_email" { unique = true; columns = [column.email] }
}

HCL vs SQL - which to author

SQL is the most common choice and the widest-supported: any feature the target DBMS accepts in DDL can be expressed.
HCL is a single, engine-neutral DSL across all supported engines.
Some DBMS-specific features (e.g., Oracle PL/SQL packages, PostgreSQL extension management) have limited HCL support - fall back to SQL schema for those (see atlas-caveats.md).

Either representation produces the same versioned migrations once diffed against the --dev-url scratch DB.