Dangerous migration linter as a GitHub app

The idea

Most production Postgres outages at small companies are self-inflicted by a migration: an innocent-looking ALTER TABLE takes an ACCESS EXCLUSIVE lock, a CREATE INDEX without CONCURRENTLY blocks writes, and the app is down for exactly as long as the table is big. The safe patterns are well documented and nobody remembers them at 4pm on a Friday.

Squawk already proves teams want this linting, but it asks you to wire a CLI into CI and keep it maintained. The wedge is packaging: an install-and-forget GitHub App that comments inline on the offending line with the specific safe rewrite, so the review conversation happens where the mistake is. Five well-known footguns cover the large majority of real incidents, which is why this fits in a weekend.

Who pays

The buyer is any team running Postgres in production with more than one engineer writing migrations, which is nearly every SaaS. At 10 to 30 dollars a month it costs less than one minute of the outage it prevents, making it an unreviewed card expense. Distribution is the GitHub Marketplace, free-for-public-repos visibility on open source projects, and SEO on postgres migration lock queries that currently resolve to blog posts rather than tools.

MVP scope

• GitHub App with webhook-driven linting of changed migration files
• Five rules covering the classic locking footguns, built on a real SQL parser
• Inline PR comments with lock explanation and the safe rewrite recipe
• Config file for migration paths and strict (check-failing) mode
• Free for public repos, paid private via Stripe payment links
• Skip for v1: MySQL, ORM-DSL parsing (Prisma schema diffs, Ruby DSL), auto-fix commits, runtime EXPLAIN against a real database, dashboards

Build MigrationGuard, a GitHub App that lints Postgres migrations in pull requests. Stack: Node.js webhook handler deployed as Vercel serverless functions, GitHub App for auth and PR access, minimal landing page on the same Vercel project. Use Vercel KV or Postgres for installation records and Stripe payment links for billing.

Core flow: team installs the app and points it at their migrations directory via a .migrationguard.yml (sensible defaults: migrations/, db/migrate/, supabase/migrations/, prisma/migrations/). On every PR, the webhook fetches changed SQL files (plus Prisma/Django/Rails migration files, parsing only the raw SQL variants in v1) and runs rule checks. Ship five rules: (1) ALTER TABLE ... ADD COLUMN with NOT NULL and no DEFAULT on Postgres versions where that rewrites the table, (2) CREATE INDEX without CONCURRENTLY, (3) ALTER COLUMN TYPE causing a full rewrite, (4) ADD CONSTRAINT without NOT VALID, (5) explicit LOCK or ACCESS EXCLUSIVE-inducing DDL mixed with data backfills in one transaction.

Each hit posts an inline PR comment on the exact line, explaining the lock it takes, roughly how long it blocks writes on a large table, and the safe rewrite spelled out, e.g. add the column nullable, backfill in batches, then SET NOT NULL with a validated check constraint. Non-blocking check by default; a strict mode in config fails the check run.

Parse SQL with pgsql-parser (libpg_query bindings) rather than regex so quoted identifiers and comments do not cause false positives.

Pricing: free for public repos, 10 GBP/month per private repo, 30 GBP/month org-wide.