Atlas Paywalled Their Migration Linter — Here Are Your Free Alternatives

What Changed in Atlas v0.38

Atlas v0.38, released October 30, 2025, restructured its pricing tiers. The key change: the atlas migrate lint command is no longer available in the free Starter plan. To use migration linting, you now need a Pro plan at $9/developer/month plus $59/CI project/month.

For a team of 5 engineers with 2 CI projects, that's $163/month for migration linting alone. Not unreasonable for a well-funded team, but a significant cost for startups, open-source projects, and smaller teams that were getting this for free.

What Atlas lint actually checked

Atlas's PostgreSQL-specific analyzers were genuinely useful. Their Pro-only rules include:

• PG301: Adding a non-nullable column without a default
• PG302: Adding a column with a volatile default
• PG303: Modifying a column type (table rewrite)
• PG304: Adding a primary key to an existing table
• PG305: Adding a unique constraint (ACCESS EXCLUSIVE)
• PG307: Creating an index non-concurrently
• PG311: Adding an exclusion constraint (table rewrite)

These are real production safety checks. If your team was relying on Atlas to catch these in CI, the paywall means you either pay up or lose that safety net.

The Community Edition and Hacker License

Atlas still offers two free options, but with limitations:

Community Edition (Apache 2.0): An open-source build of Atlas with the basic migration engine. It includes migrate lint with a basic set of analyzers, but the PostgreSQL-specific rules (PG301-PG311) are Pro-only. You get generic checks like destructive change detection, but not the nuanced PostgreSQL lock and rewrite analysis that made Atlas lint valuable.

Hacker License: Free for students, open-source contributors, and hobby projects. This is generous, but it explicitly excludes commercial use. If your company is running PostgreSQL in production, you cannot use the Hacker License for your CI pipeline.

The Broader Trend: Paywalls Everywhere

Atlas is not alone in restricting free tiers. Within a 6-month window in 2025:

• Liquibase changed to a Functional Source License (FSL) in October 2025. FSL is not OSI-approved open source. Apache Fineract has already downgraded their Liquibase dependency, and CNCF projects cannot use FSL-licensed software.
• Flyway discontinued their Teams tier in May 2025, leaving only Community (limited) and Enterprise (expensive, quote-based).
• Atlas moved lint to Pro in October 2025.

Three major migration tools restricting access within six months is not a coincidence — it's a market consolidation pattern. If you want migration safety tooling that will remain free and open source, the options are now more limited than they were a year ago.

Free, Open-Source Alternatives

If you need a free PostgreSQL migration linter in CI, here are your options, assessed honestly:

1. Squawk

Squawk is the most established free migration linter. Written in Rust, it's fast and focused.

Strengths: Fast execution (Rust native), well-tested rules for common PostgreSQL lock hazards, active development. The core rules cover CREATE INDEX without CONCURRENTLY, adding columns with volatile defaults, and other common issues.

Limitations: No lock type classification (doesn't tell youwhich lock a statement acquires). No production context awareness — it can't factor in table sizes or active queries. No auto-fix suggestions. Exit code 1 for both errors and warnings (no distinction). Cannot analyze PL/pgSQL function bodies or DO blocks.

# Install and run Squawk
npm install -g squawk-cli

# Analyze a migration file
squawk migrations/V1__add_users_email.sql

# In CI (GitHub Action)
# Uses: sbdchd/squawk-action@v1

2. strong_migrations (Rails only)

If your team uses Ruby on Rails, strong_migrations is the gold standard. It integrates directly with ActiveRecord and catches dangerous migrations at the ORM level.

Strengths: Excellent developer experience — when a migration is dangerous, it shows you the exact safe alternative with a clear explanation of why. This "explain the risk, show the fix" UX is what every migration linter should aspire to.

Limitations: Rails and ActiveRecord only. If your team uses Go, Python, Node.js, or plain SQL files, strong_migrations is not an option. This is the most common complaint in migration safety discussions:

"My conundrum is we don't use Django lol. Wish this sort of thoroughness existed in standalone pg migration tooling." — Hacker News commenter

3. Eugene

Eugene is a newer tool that takes a unique approach: both static lint and dynamic lock tracing. It can run your migration against a temporary PostgreSQL server and observe which locks are actually acquired.

Strengths: The dynamic tracing approach can catch issues that static analysis misses. Supabase's postgres-language-server team has acknowledged that Eugene is "more advanced" than their Squawk-based port for lock analysis.

Limitations: Very early-stage (52 stars). Requires a running PostgreSQL instance for dynamic tracing. No GitHub Action in the marketplace. Smaller community and less documentation.

4. MigrationPilot

MigrationPilot is a newer entry with the deepest free rule set. Disclaimer: this article is published on the MigrationPilot blog, so take this section with appropriate skepticism and verify the claims against the open-source repository.

Strengths: Lock type classification (tells you which lock each statement acquires). Risk scoring (RED/YELLOW/GREEN). Auto-fix suggestions for 12 rules. Works with any framework — analyzes plain SQL. Free GitHub Action. VS Code extension. Every rule includes an explanation of why the operation is dangerous and the safe alternative.

Limitations: New project with a small community. Fewer real-world battle-testing hours than Squawk. TypeScript, not Rust — slower on very large migration files (though still sub-second for typical migrations). The 3 paid rules require a $19/month subscription for production context analysis.

# Install and run MigrationPilot
npx migrationpilot analyze migrations/*.sql

# Auto-fix common issues
npx migrationpilot analyze migrations/*.sql --fix

# In CI (GitHub Action)
# Uses: mickelsamuel/migrationpilot@v1

Comparison Table

Migration Guide: Switching from Atlas Lint

If you were using atlas migrate lint in your CI pipeline, here is how to switch to a free alternative. The examples below use MigrationPilot, but the same concept applies to Squawk.

GitHub Actions

Replace your Atlas lint workflow step:

# Before: Atlas (now requires paid Pro plan)
- uses: ariga/atlas-action/migrate/lint@v1
  with:
    dir: file://migrations
    dev-url: "sqlite://dev?mode=memory"

# After: MigrationPilot (free)
- uses: mickelsamuel/migrationpilot@v1
  with:
    paths: migrations/*.sql
    fail-on: critical

Local development

# Before: Atlas
atlas migrate lint --dir file://migrations --dev-url "postgres://..."

# After: MigrationPilot
npx migrationpilot analyze migrations/*.sql

# Or install globally
npm install -g migrationpilot
migrationpilot analyze migrations/*.sql

Rule mapping: Atlas to MigrationPilot

Here is how Atlas's PostgreSQL-specific rules map to MigrationPilot rules:

MigrationPilot covers all of Atlas's PostgreSQL-specific rules, plus 73 additional checks that Atlas does not have — including foreign key lock analysis, lock_timeout enforcement, VACUUM FULL detection, enum type safety, trigger cascade analysis, and more.

When You Should Still Use Atlas

This is not an anti-Atlas article. Atlas is a good product with capabilities that go beyond linting:

• Multi-database support: If you run MySQL, MariaDB, SQLite, and PostgreSQL, Atlas handles all of them. Squawk and MigrationPilot are PostgreSQL-only.
• Schema-as-code: Atlas's declarative HCL schema and drift detection are features that linters don't provide.
• Managed migration planning: Atlas can generate migration files from schema diffs, which is a migration runner feature, not a linter feature.
• Enterprise features: Audit trails, access control, and deployment orchestration for larger teams.

If your team needs a full migration management platform and can justify the cost, Atlas Pro is still a strong choice. The alternatives listed here are specifically for teams that need free, open-source migration linting in CI.

The Bigger Question: Why Lint Migrations at All?

If you are considering dropping migration linting from your CI pipeline rather than switching tools, consider the cost of not linting:

• GoCardless had a 15-second API outage from a foreign key constraint that locked two tables simultaneously.
• Resend suffered a 12-hour outage from a production DROP operation.
• Every CREATE INDEX without CONCURRENTLY on a table with more than a few thousand rows blocks all writes until the index build completes.
• Every ALTER TABLE ... SET NOT NULL without the CHECK constraint pattern scans the entire table under an ACCESS EXCLUSIVE lock.

These are not theoretical risks. They are recurring patterns that cause production incidents at companies of every size. A migration linter in CI is the cheapest insurance against these issues — it catches the mistake before it reaches production, not after.

Summary