Veto vs Squawk
Squawk is the Postgres migration linter you run in CI. Veto is the deterministic check your AI agent calls over MCP before it executes a statement.
Alternative to Squawk?
If you searched alternative to Squawk because an AI coding agent runs SQL outside your PR pipeline — Veto is that alternative category: a real-time MCP gate with ok / warn / block, not a migration linter replacement. For CI linting, keep Squawk; for the agent loop, add Veto.
At a glance
| Squawk | Veto | |
|---|---|---|
| When it runs | CI / pre-commit on migration files | Runtime — before each statement the agent executes |
| Interface | CLI, GitHub Action, pre-commit hook | MCP tool (analyze_sql) over HTTP |
| Primary focus | Lock-heavy schema changes, migration anti-patterns | Destructive DML/DDL, correctness traps, cost (EXPLAIN), custom org policies (Pro) |
| AI agent loop | Not in the agent's tool list | Built for Claude Code, Cursor, Cline, … |
| Connects to your DB | No — static analysis of SQL text | No — optional EXPLAIN on scratch Postgres only |
| Verdict | Lint warnings / rule violations | Structured ok / warn / block with stable finding ids |
When Squawk is the right tool
You want every migration file in a PR reviewed for operations that cause long locks — adding NOT NULL without a backfill, creating indexes without CONCURRENTLY, and similar schema-change footguns. Squawk is mature, open source (Apache-2.0), and integrates cleanly with GitHub Actions.
One tradeoff worth stating plainly: Squawk runs entirely on your machine — your SQL never leaves it. Veto is a hosted service today, so statements are sent to its endpoint for analysis (it stores only the verdict and which rules fired, never your SQL or schema). If zero egress is a hard requirement right now, that's a genuine point for Squawk; Veto's self-host is on the roadmap.
When Veto is the right tool
Your AI coding agent writes and runs SQL interactively — ad-hoc queries, one-off fixes, migrations outside a PR pipeline. The agent won't invoke Squawk before DELETE FROM users;. Veto sits in the MCP loop and returns a reproducible block before the statement hits the database.
Use both
The strongest setup for teams using AI agents: Squawk in CI on checked-in migrations, Veto at runtime on whatever the agent generates. Squawk catches migration craft; Veto catches agent-generated destructive SQL and statements that never went through a PR.
Is Veto a Squawk replacement?
No — and it isn't trying to be. Veto doesn't replace a migration-lint workflow. If you need an alternative to Squawk for CI, Squawk (or similar static linters) remain the right category. Veto fills the gap Squawk was never designed for: a deterministic pre-execution gate inside an autonomous agent loop.