Schema migration impact analysis

See what a schema migration breaks before it runs

Schemity's impact analysis reads a pending schema change, or a migration file written anywhere else, against your live PostgreSQL, MySQL, MariaDB, SQL Server or SQLite database, and tells you what it costs before anything runs: the rows it loses, the statements that will fail on existing data, the tables it rewrites, how long it holds back reads and writes, and every view, trigger and function in the way. Each finding carries a number from the live catalogue. Nothing is executed; a count runs only when you ask for one.

Download free trial How to use it

2 weeks, no credit card. macOS, Windows, Linux.

Impact (3) · PostgreSQL 18

ALTER TABLE orders ALTER COLUMN total TYPE bigint;

Rewrites the table: Rewrites orders to change total: ~1M rows, 87 MB on disk
Holds back other statements: Changing the type of total holds back reads and writes to orders while it reads ~1M rows
Dependent objects: 2 objects depend on orders.total, and the database refuses the change: view order_summary, materialized view order_totals

From a real run on PostgreSQL 18.3. PostgreSQL itself names only the first view.

What it reports

What does impact analysis report?

Findings are grouped by what they cost, in this order. They are facts with numbers, never severity levels, and the report never tells you not to proceed.

Loses data

A dropped table or column, or a type change that cannot keep every value, such as text to integer or a narrower varchar.

Can fail on existing data

SET NOT NULL over nulls, a NOT NULL column with no default, a unique key over duplicates, a foreign key over orphan rows, a check the rows were never tested against.

Storage engine

MySQL only: a foreign key on a MyISAM table is accepted and silently not stored, and one referencing such a table is refused.

Rewrites the table

A type change the engine performs by copying the table, or a new column whose default is computed for every row, with the row count and size on disk.

Holds back other statements

Whether writes wait, or reads and writes, while the statement builds an index, checks a key or NOT NULL, or changes a type.

Dependent objects

Views, materialized views, triggers, functions, procedures and generated columns, each with what the change does to it.

Spreads through the diagram

A key other tables reference, followed through every foreign key with the hop count and the context views it reaches.

Changes data

Migration files only: how many rows an UPDATE, DELETE or INSERT can touch, with the WHERE clause shown.

Schemity's Impact drawer after changing orders.total from INTEGER to BIGINT: a table rewrite of about 1M rows and 87 MB, reads and writes held back on orders, and 2 objects depending on orders.total that make the database refuse the change, the view order_summary and the materialized view order_totals, shown on the canvas next to orders — The Impact drawer (F7) on a connected diagram. The badge on the toolbar keeps the count current as you edit.

Locks

Will this migration lock the table?

It depends on the database, and the answer is per statement. These are the holds impact analysis reports, each run against PostgreSQL 17, MySQL 8.4 and SQL Server 2022 on 2026-09-21, including timed runs on multi-million-row tables. Every ALTER takes a strong lock for an instant; only the work that grows with the table is listed. Tables under 10,000 rows are skipped, since the lock is over before anyone waits.

Change	PostgreSQL	MySQL (InnoDB)	SQL Server
Build an index	Writes wait (none with CONCURRENTLY in a file)	Writes continue	Writes wait
Add a foreign key	Writes wait	Writes wait (table copied)	Writes wait
Add a unique key or primary key	Reads and writes wait	Writes continue	Writes wait
Add a check constraint	Reads and writes wait	Writes wait (table copied)	Writes wait
SET NOT NULL	Reads and writes wait	Writes continue	Reads and writes wait
Type change that rewrites	Reads and writes wait	Writes wait	Reads and writes wait

SQLite locks the whole database for any write, so there is nothing to tell apart. On PostgreSQL a new foreign key also holds back writes on the table it references; only the scanned table is reported. Sources: PostgreSQL ALTER TABLE, MySQL 8.4 online DDL.

Dependents

Will dropping or changing a column break a view?

The database decides, and each one decides differently. Impact analysis reads how each object is bound to the table and reports what the change does to it.

Object	Drop or retype the column	Rename the column
PostgreSQL view or materialized view	Refused while the view exists	The view follows the new name
SQL Server view WITH SCHEMABINDING	Refused	Refused
MySQL view, SQL Server view without schema binding	Succeeds; the view may fail the next time it runs	Succeeds; the view may fail the next time it runs
PostgreSQL trigger whose UPDATE OF or WHEN names the column	Refused	The definition follows; the trigger function may not
Generated column that reads it	Drop refused everywhere; a type change is refused on PostgreSQL and SQL Server, recomputed on MySQL and SQLite	Follows on PostgreSQL and SQLite, refused on MySQL and SQL Server

A name found in a function or procedure body is worded "mentions", never "depends on", because a name match is not proof. SQLite keeps no record of what a view reads, so views are not checked there.

Migration files

Can it check a migration file I did not write in Schemity?

Yes, as SQL. Press Shift+F7, open one or more .sql files or paste the SQL, and Schemity reads them against the connected database with nothing executed. Prisma, Flyway, golang-migrate and hand-written migrations are SQL already; for Alembic or Django, export the SQL first with alembic upgrade --sql or sqlmigrate.

In the order your tool runs them

Flyway's V2 before V10, timestamped names in time order, Prisma's migration folders by folder. Each finding names its file.

Rollbacks left out

golang-migrate's .down.sql and Flyway's U2__ undo files are skipped, so the report describes the migration that will run.

Every statement accounted for

Bookkeeping tables such as _prisma_migrations and flyway_schema_history are skipped; a CREATE FUNCTION or DO block lands under Not analysed with the reason.

Data changes counted

UPDATE, DELETE and INSERT get a Changes data finding; a simple WHERE can be counted exactly, one with a function call or subquery is shown but never run.

Real cases

What does it catch on a real database?

Each of these posts runs a common change against a real database and shows the findings on screen.

PostgreSQL Cannot alter type of a column used by a view INTEGER to BIGINT refused by a view and a materialized view; the error names only one. PostgreSQL Adding a NOT NULL column to a large table Which way of adding it holds back reads and writes on millions of rows, and which does not. PostgreSQL Unique constraint vs unique index The constraint holds back reads and writes; the index only writes. PostgreSQL Changing ON DELETE Changing a referential action drops and recreates the foreign key. MySQL UNSIGNED to signed primary keys A key type change that has to drop and re-add the foreign keys around it. PostgreSQL Renaming updated_at PostgreSQL accepts the rename; the trigger that sets the column fails on the next UPDATE. SQL Server INT to BIGINT primary key Rewrites, holds, and the spread through every referencing foreign key. SQLite Changing a column type in SQLite The rebuild drops every trigger and index on the table, and can delete child rows through ON DELETE CASCADE.

Compared

How is this different from migration linters?

Most tools read the migration text against fixed rules, or run it on a copy and watch. Schemity reads the text against the live catalogue: real row counts and sizes, and the actual views, triggers and generated columns in the way.

	How it knows	Dependent views refusing a change	Counts on your data	Databases	Draws the change
Schemity	Live catalogue, nothing executed	Yes, per database	On request (nulls, duplicates, orphans)	PostgreSQL, MySQL, MariaDB, SQL Server, SQLite	Yes, on the ERD
Atlas migrate lint	Rules plus a dev database	Not documented	No	Many	Yes, ERD in Pro
squawk	Rules on the SQL text	No	No	PostgreSQL	No
strong_migrations	Raises when the Rails migration runs	No	No	PostgreSQL, MySQL, MariaDB	No
Eugene	Rules, or runs it on a temporary Postgres and records locks	Not documented	No	PostgreSQL	No
Bytebase SQL Review	Rules, some with EXPLAIN	Not documented	No	Many	No
Flyway code review	Rules on the SQL text	No	No	Many	No

Sources, checked October 2026: Atlas, squawk, strong_migrations, Eugene, Bytebase, Flyway.

What Schemity does not do

It is not a CI gate, and it does not run a migration online. To block a pull request on a rule, a linter such as squawk or Atlas belongs in your pipeline; to change a huge table without downtime, an online schema change tool does the running. Schemity is where you read the cost first, on the database you are about to change.

Questions

What is schema migration impact analysis?

Reading a schema change against the database it will run on, before it runs, to find what it costs: data it loses, statements that fail on existing rows, table rewrites, locks, and the objects that depend on what changes.

Does impact analysis run anything on my database?

It reads the catalog: row estimates, sizes, and the objects that depend on a table. The only other query is a count you ask for on one finding, with a 60-second timeout, inside a read-only transaction on PostgreSQL and MySQL. The migration itself is never executed.

Does ALTER COLUMN TYPE rewrite the table?

On PostgreSQL, when the new type is not binary-compatible with the old; on MySQL, a column type change copies the table; on SQL Server a type change rewrites; SQLite rebuilds the table. Impact analysis reports which, with the row count and size on disk.

Which databases does it support?

PostgreSQL (including Supabase), MySQL, MariaDB, SQL Server and SQLite, on a diagram connected to the live database. Snowflake diagrams have no live connection, so impact analysis does not apply to them.

Can an AI agent use it?

Yes. Through Schemity's local MCP server, analyze_impact returns the findings for the pending changes and analyze_migration_file for a migration the agent wrote, with nothing executed.

How much does it cost?

It is part of the desktop app: $129 once, no subscription. It runs during the 2-week trial, and is not part of the free browser version.