safe-not-safe checks Postgres migrations with a WASM build of Postgres's own parser

A migration checker built on Postgres's real grammar

A project called safe-not-safe reached Hacker News's front page on 26 September with a simple pitch: hand it a SQL migration file and it will tell you whether the change is safe to run against a production database. According to the project's site at safenotsafe.dev, the tool ships in two forms — a browser-based checker and a command-line interface invoked with npx safe-not-safe check migration.sql.

The notable technical choice is the parser. The tool's output, quoted in the Hacker News listing, shows it parses SQL using libpg_query 17 compiled to WebAssembly — that is, the parser lifted from PostgreSQL 17 itself rather than a hand-written approximation of the SQL dialect. Parsing migrations with the database engine's own grammar means the tool sees statements exactly as the server would see them, including the syntax corner cases that lighter-weight parsers tend to mishandle.

Everything runs client-side

The web version of the checker is fully local, per the site's own status messages: it downloads and compiles the libpg_query WASM module inside a browser worker, so the SQL you paste is parsed on your machine rather than shipped to a backend. For teams whose schema files are considered sensitive, that architecture removes the usual objection to paste-and-check web tools.

The interface reports the basics you would expect from a static checker: a statement count, the character count of the input, and a tally of flagged statements — the empty state shows "0 flagged of 0" — along with bundled sample migrations to try. The CLI mirrors the same pipeline for use in local checks or CI pipelines.

What "safe" means here

It is worth being clear about the limits of the available information: the source material for this story is essentially the tool's interface text, and it does not enumerate which specific hazards the checker detects. The exact rule set is therefore not documented in the published material.

The problem class it targets, however, is well understood. Schema migrations are one of the most common ways otherwise stable PostgreSQL deployments fall over. Operations that take aggressive locks — for example, creating an index without CONCURRENTLY, which blocks writes on the table for the duration of the build — can freeze an application behind a single lock. Commands that rewrite entire tables, such as altering a column's type on a large, hot table, can hold that lock for minutes or hours. Even adding constraints or defaults can carry costs that surprise teams deploying under load. Static checkers in this space, such as Ruby's strong_migrations and similar linters in other framework ecosystems, exist precisely to catch these patterns at review time rather than during a deploy.

Whether safe-not-safe covers all of these cases, and how it weighs false positives against missed hazards, is not something the front-page material establishes.

Why it matters

Migration safety is a review-time problem that most teams still solve informally, by hoping the senior engineer on duty remembers which ALTER TABLE variants rewrite the table. A checker that runs against the actual PostgreSQL grammar, distributes friction-free through npx, and processes SQL locally in a browser worker lowers the cost of adopting that check dramatically — there is no server to run, no schema to upload, and no dependency on a third-party service seeing your DDL.

The libpg_query-in-WASM approach is also a quietly important pattern. PostgreSQL's parser is the authoritative definition of what the server will accept, and compiling it to WebAssembly means browser tooling can now share that exact definition instead of approximating it. If safe-not-safe's rule set proves thorough, it points toward a future where "is this migration safe?" is a question answered by a local, offline tool in every pull request rather than a postmortem after the lock timeout.

For now, the tool is a front-page newcomer: promising in architecture, light on documented specifics, and easy enough to try that any team shipping Postgres migrations can evaluate it against their own change history in minutes.