Is your Postgres migration safe or not safe?
A former Cloudflare Postgres platform lead launched safe-not-safe, a browser-based tool using WASM to statically analyze PostgreSQL schema migrations for common risks.
summary is enough The tool provides a quick browser-based static check for SQL migrations, while the comment thread offers practical nuances about database locking and state dependencies.
summary
Safe-not-safe is a browser-based utility that parses PostgreSQL DDL statements via a WASM-compiled libpg_query to flag risky migrations locally without telemetry. Created by a former Cloudflare Postgres team lead, it targets low-hanging fruit and common migration mistakes before they reach CI. However, commenters point out the inherent limits of static rules, noting that true safety often depends on live database state, table size, and lock queuing dynamics.
key points
- The tool runs entirely in the browser using a WASM-compiled PostgreSQL parser, ensuring zero telemetry or data upload.
- Commenters emphasize that static analysis cannot catch state-dependent issues, such as column type rewrites or lock queueing behind long-running queries.
- Experienced operators recommend combining linters with operational safeguards like short lock_timeout settings and testing against replicas.
who should read it
Database administrators, backend engineers, and platform teams managing PostgreSQL migrations.
discussion positive
consensus
Most commenters appreciate the lightweight, browser-based approach for catching obvious errors, but strongly emphasize that static rule checkers are insufficient on their own for production safety.
pushback
A minority argue that static linters provide a false sense of security, pointing out that true migration safety requires introspecting live database state, table sizes, or handling zero-downtime application rollouts.
These kinds of rule-based migration safety checks are simple, but hardly complete.
The problem is that some migration safety depends on the state of the database, which isn’t represented in the DDL statement alone. For example, altering a column type is either a no-op or an exclusive locked table rewrite depending on the original type of the column.
There are other footguns that can happen if the column you’re altering is a foreign key, where multiple tables can be locked.
I went down a rabbit hole a few years ago and built a system[1] to introspect a given migration against a live schema, …
It explains why static DDL checks are incomplete without live database state introspection and lock analysis.
Generated by an LLM from the article and thread. Check the sources before relying on it.