WoluTools
Find a tool

Developer Tools

Compare two PostgreSQL schemas and spot what was removed

Upload the schema before and after as SQL. You get the tables, views and indexes that were added, removed or changed. Columns are not compared one by one.

or drop it here

SQL · Up to 50,000 schema objects
Free account needed for your 3 free jobs a day

No file at hand? See the prepared example

Standard toolIncluded · 3 free jobs a dayFree: 3 jobs a dayPro: up to 200 jobs a day · €12.99/month or €89.99/year
  • SQL
  • Up to 50,000 schema objects
Prepared result preview · fictional sample dataFictional PostgreSQL DDL Object-Level Diff fixture
Source
2 prepared source files · 51 bytes
Reconciliation evidence
  • Objects before: 1
  • Objects after: 1
  • Changes: 1

schema-diff.csv · findings.csv · manifest.json

BringSQL
GetObject-level schema diff CSV, removal findings and manifest
PrivacyEncrypted source · 24-hour result

One clear job, from source to download

  1. 1

    Add the source

    Supported formats and limits are visible before the upload.

  2. 2

    Confirm the settings

    Review the exact source, options, units and access before processing.

  3. 3

    Inspect and download

    Check the preview and warnings, then unlock the complete package.

See which PostgreSQL objects a migration removes

Two SQL files, before and after

You upload the schema before and after a change as SQL files. The tool reads top-level CREATE TABLE, CREATE VIEW and CREATE INDEX statements, up to 50,000 objects. It is PostgreSQL only, so syntax from MySQL or SQL Server is not recognised, and the job says what it could not parse. Both files are read as text. Nothing connects to a database and no SQL is run.

The diff table and the removals list

You download schema-diff.csv, which lists each object as added, removed or changed. Objects are matched by name and compared as text, so an altered table shows as changed without a column-by-column breakdown. findings.csv lists every object that exists before and is missing after, because a dropped table or index is the change most worth a second look. A manifest.json file records which files were compared and a summary of the counts.

What stays your call before deploying

There are no settings to choose. The tool only reports facts it can read from your two files. It does not judge whether a column change is safe and never labels a migration script as safe. A statement it cannot identify is reported, not skipped. Use the removals list to decide what to check before you deploy, and keep your normal review and testing in place. The result supports that review and does not replace an engineer's decision.

Questions before you run it

Which PostgreSQL statements does the diff read?

Top-level CREATE TABLE, CREATE VIEW and CREATE INDEX definitions in the SQL files you supply, up to 50,000 objects. Statements it cannot identify are reported rather than skipped in silence.

Does it compare individual columns?

No. Objects are matched by name and compared as text, so an altered table shows up as changed without a column-by-column breakdown. Column-level semantic safety is not claimed.

Is any SQL run against my database?

No. Both files are read as text. Nothing connects to a server, and no migration script is executed or labelled safe by this tool.

How are dropped tables and indexes reported?

An object present in the before file and missing from the after file is listed in findings.csv as a removal, since that is the change class most worth a second look before a deploy.

Does it handle MySQL or SQL Server dumps?

The parser is PostgreSQL-only in this first version. Syntax specific to other engines will not be recognised, and the job states what it could not parse.