Schema Autopsy
Paste a database schema and see what is wrong with it: missing primary keys, references to tables that do not exist, undeclared relationships, islands, and, with row counts, the tables that exist and hold nothing. Structure only, in your browser.
Paste the structure of a database and this tells you what is wrong with it: tables with no primary key, foreign keys pointing at tables that do not exist, columns that look like references but are not declared as any, tables nothing links to, and, if you give it row counts, the tables that exist and hold nothing. Structure only. It never needs a row of data, a credential or a connection, and nothing you paste leaves your browser.
Most databases will give you this in one query from their information schema. Counts turn a structural review into a finding about what the system actually holds, which is usually the part nobody has looked at.
The sample is illustrative. It is a small invented schema seeded with the defects this tool looks for, so you can see what a result looks like before pasting your own. Its tables, names and counts are not real data.
What it looks for, and why each one matters
Tables with no primary key. Rows that cannot be addressed cannot be safely updated, deleted or replicated. Almost every replication and change-capture tool refuses or silently degrades on such a table, and it is the first thing a migration assessment finds.
References to tables that do not exist. A foreign key pointing at a table that is not in the schema is either a table that was dropped, a rename that was not followed through, or a schema pasted from two systems. In every case something believes a relationship exists that the database cannot enforce.
Columns that look like references and are not declared as any. A column named like a key with no constraint behind it is a relationship the application enforces on a good day and nothing enforces on a bad one. These are where orphaned rows come from.
Tables nothing links to and that link to nothing. In a schema where most tables are connected, an island is usually a feature that was started and abandoned, a staging table that became permanent, or an import that was never wired in.
Empty tables, when you supply counts. This is the finding that surprises people. A table exists because somebody designed a feature. An empty one means the feature was designed and never used, or was used and then quietly abandoned. The proportion of a schema that is empty is a direct measure of how much of the system is fiction.
Very wide tables, and mixed naming. A table with dozens of columns is usually several entities that were never separated. Two naming conventions in one schema is the fingerprint of two teams or two eras, and it tells you where to expect the seams.
What it cannot see: indexes, data types in any depth, query patterns, or anything about the rows themselves beyond the counts you give it. It is pattern matching over structure, and it is honest about that. A real assessment reads the data too. This is the free first hour, and it is deliberately the part that needs no trust from you.
It runs entirely in your browser and nothing you type is transmitted or stored. The output is indicative and derived from your own inputs, so it is only as good as they are. It is educational material, not professional, financial, legal or tax advice, and it is not an audit, a quote or a substitute for review by someone who can see your actual environment.
- Data Engineering Knowledge Hub
- Database Migration Assessment Tools