1. Safe additive change

Low risk
1Tables Added
0Tables Removed
1Tables Modified
0Breaking Changes
12 Safe

Migration Safety Score

Only additive changes โ€” new nullable columns and a new table. Safe to deploy with standard monitoring.

Breaking Changes

  • noneNo breaking changes detected ๐ŸŽ‰

Migration SQL

CREATE TABLE order_items ( id SERIAL PRIMARY KEY, order_id INTEGER NOT NULL REFERENCES orders(id), product_name VARCHAR(255) NOT NULL, quantity INTEGER NOT NULL, price DECIMAL(10,2) NOT NULL ); ALTER TABLE orders ADD COLUMN shipped_at TIMESTAMP, ADD COLUMN tracking_number VARCHAR(100); CREATE INDEX idx_order_items_order ON order_items(order_id);

2. Column type widening

Medium risk
0Tables Added
0Tables Removed
1Tables Modified
1Breaking Changes
48 Risky

Migration Safety Score

Widening a column type is usually safe, but it can cause subtle issues with ORM mappings, query plans, and downstream ETL.

Breaking Changes

  • mediumPossible data-truncation or ORM-mapping risk: users.bio changed from VARCHAR(500) to TEXT

Migration SQL

ALTER TABLE users ALTER COLUMN bio TYPE TEXT;

3. Destructive column changes

High risk
0Tables Added
0Tables Removed
2Tables Modified
3Breaking Changes
82 Dangerous

Migration Safety Score

Dropping a column and adding NOT NULL without a default are destructive changes. Requires code changes, backfill, and careful rollout.

Breaking Changes

  • highColumn dropped: orders.legacy_notes
  • highNOT NULL added without default: users.phone
  • mediumIndex dropped: idx_orders_legacy

Migration SQL

-- Backfill data before applying NOT NULL UPDATE users SET phone = '' WHERE phone IS NULL; ALTER TABLE users ALTER COLUMN phone SET NOT NULL; ALTER TABLE orders DROP COLUMN legacy_notes; DROP INDEX idx_orders_legacy;

Rollback SQL

ALTER TABLE orders ADD COLUMN legacy_notes TEXT; ALTER TABLE users ALTER COLUMN phone DROP NOT NULL; CREATE INDEX idx_orders_legacy ON orders(legacy_notes);

4. Table rename + foreign-key updates

High risk
1Tables Added
1Tables Removed
2Tables Modified
2Breaking Changes
76 Dangerous

Migration Safety Score

Renaming a table breaks every query, foreign key, and ORM reference. Requires coordinated code and migration deployment.

Breaking Changes

  • highTable dropped: customers (detected as rename to clients)
  • highForeign key references updated: orders.customer_id โ†’ orders.client_id

Migration SQL

ALTER TABLE customers RENAME TO clients; ALTER TABLE orders DROP CONSTRAINT fk_orders_customer_id, RENAME COLUMN customer_id TO client_id, ADD CONSTRAINT fk_orders_client_id FOREIGN KEY (client_id) REFERENCES clients(id);

5. No schema changes

Low risk
0Tables Added
0Tables Removed
0Tables Modified
0Breaking Changes
0 Safe

Migration Safety Score

No schema differences detected. The action can be configured to skip further steps when there are no changes.

Breaking Changes

  • noneNo breaking changes detected ๐ŸŽ‰

Migration SQL

-- No migration needed. Schema is unchanged.

Get schema diff reports on every PR

The SchemaLens GitHub Action generates these reports automatically for PostgreSQL, MySQL, SQLite, SQL Server, and Oracle โ€” no license key required.

Frequently asked questions

Are these real reports?

They are realistic examples generated with the same engine that powers the SchemaLens GitHub Action. The layout matches the self-contained HTML report artifact.

Can I download these as HTML files?

Yes โ€” install the GitHub Action and set upload-report: true. Every PR will produce a downloadable, offline-ready HTML report.

What databases are supported?

PostgreSQL, MySQL, SQLite, SQL Server, and Oracle. The report format is the same for every dialect.

Do I need a paid license?

No. Schema diff reports, migration SQL, rollback SQL, and drift alerts are free forever. The Team plan adds shared workspaces, persistent alert history, and admin controls.