Comparison
Squawk vs pgfence
An honest comparison of two Postgres migration linters: Squawk (Rust, SQL-only) and pgfence (TypeScript, multi-ORM with safe rewrite guidance).
What Squawk does well
Squawk is a Rust-based Postgres migration linter with an official GitHub Action. It also covers broader SQL authoring workflows with goto-definition, hover, completions, and inlay hints.
If your team writes raw SQL and wants a fast lint pass in CI alongside rich editor features for general SQL authoring, Squawk is a solid choice.
Feature comparison
| Feature | Squawk | pgfence |
|---|---|---|
| Language | Rust | TypeScript (Node.js native) |
| SQL parser | Custom parser (CST-level access) | libpg_query (PostgreSQL's actual parser) |
| Rule surface | Focused SQL lint rule set | Broad migration-safety rule set |
| Trace mode | No | Yes (Docker-based, verifies locks against real PG) |
| Input: raw SQL | Yes | Yes |
| Input: TypeORM / Prisma / Knex / Sequelize / Drizzle | No (can pipe Django/Alembic output) | Yes (built-in ORM extractors) |
| Lock mode reporting | Implicit (in rule descriptions) | Explicit per statement |
| Safe rewrite recipes | Links to docs | Step-by-step safe rewrite guidance in output |
| DB-size-aware risk scoring | No | Yes (stats snapshot or direct connection) |
| VS Code extension | Yes (SQL IDE: goto-def, completions, inlay hints) | Yes (migration-focused: diagnostics, supported quick fixes, hover) |
| Output formats | Terminal, GitHub | Terminal, JSON, GitHub PR comment, SARIF |
| GitHub Action | Yes (first-party GitHub Action) | Yes (repo-level composite action) |
| Coverage reporting | No | Yes (analyzed vs. unanalyzable statements) |
| Policy checks | Some (timeout-setting lint) | Yes (lock_timeout, statement_timeout, tx policy) |
Different focus areas
Squawk covers more than migration linting. It also ships broader SQL authoring features with its own parser, including goto-definition, completions, and inlay hints.
pgfence is focused specifically on migration safety: lock mode analysis, risk scoring, trace verification, and safe rewrite guidance. Its editor integration is built around migration diagnostics and quick fixes for supported executable rewrites rather than general SQL authoring.
When to choose Squawk
- Your team writes raw SQL migrations exclusively
- You want a Rust binary with zero Node.js dependency
- You want a full SQL IDE experience (goto-def, completions, inlay hints) alongside migration linting
When to choose pgfence
- Your team uses TypeORM, Prisma, Knex, Sequelize, or Drizzle migrations
- You want to know the exact lock mode each statement takes and what it blocks
- You want trace mode to verify lock predictions against real PostgreSQL
- You want step-by-step safe rewrite guidance directly in the output for supported patterns
- You need table-size-aware risk scoring
- You want SARIF output for GitHub Code Scanning annotations
- You want policy enforcement: missing
lock_timeout,CONCURRENTLYinside transactions - Your stack is Node.js/TypeScript
Both tools use the real parser (differently)
Squawk uses its own custom parser that provides CST-level access, needed for its IDE features. pgfence uses libpg_query, PostgreSQL's actual parser compiled to a C library. Both handle edge cases that regex-based linters miss.
The difference is in what they do after parsing. Squawk applies lint rules and powers IDE features. pgfence maps each AST node to a specific lock mode and risk level, then attaches safe migration guidance when it has a known rewrite.