# Reverse-Engineer an Existing Database

> Generate an ERD from an existing database or a SQL dump. Import live schemas or CREATE TABLE statements, document a production database schema, offline with Schemity.

Source: https://schemity.com/doc/reverse-engineer-database/

Reverse-engineering turns a database you already have into a diagram you can read. Whether you inherited a schema, need to **document a production database schema**, or just want a map before a refactor, Schemity builds the ERD for you. Both methods below are licensed desktop features.

## How do I reverse-engineer a database into an ERD?

### From a live connection

Create a diagram, click **Connect to a database**, and set **Connect via** to **Direct connection** or **SSH Tunnel** (see the per-engine guides for [PostgreSQL](https://schemity.com/doc/connect-postgresql/), [MySQL](https://schemity.com/doc/connect-mysql/), [SQL Server](https://schemity.com/doc/connect-sql-server/), and [SQLite](https://schemity.com/doc/connect-sqlite/)). Schemity introspects the database and draws every table automatically - there is no table-selection step.

### From a SQL dump

No live access? Schemity can **generate an ERD from a SQL dump**. Use **Import SQL** and paste the `CREATE TABLE` statements (and any `ALTER TABLE` or `CREATE INDEX`), or click **Open file...** to load a `.sql` file. Schemity parses them as the diagram's database (PostgreSQL, MySQL, SQL Server, SQLite, or Snowflake), and the drawer names which one it is reading as. For Snowflake, paste the script `GET_DDL` returns and the diagram starts from your existing tables, with types named as Snowflake reports them; [Snowflake schema design](https://schemity.com/doc/snowflake/) has the steps. This is the safest path for sensitive systems: you never connect to production, you just **import CREATE TABLE to an ERD** from an exported file.

![The Import SQL drawer on a MySQL diagram, saying it reads CREATE TABLE and ALTER TABLE statements as MySQL, with Open file and Preview import buttons](https://schemity.com/images/doc/reverse-engineer-database/import-sql.webp)

### What happens when I import SQL into a diagram that already has tables?

Import SQL updates the diagram instead of duplicating it. Click **Preview import** and every table in the script is listed as **New**, **Updated**, or **Unchanged** against what the diagram already holds. Import never removes a table: one the script does not mention stays as it is. The whole import is a single undoable change, so one Undo takes it back.

That makes Import SQL a way to keep a design-only diagram current from a schema dump: export the DDL again after a migration, import it, and only what changed moves.

### What if the script holds more than tables?

Schemity reads the script one statement at a time. Views, grants, functions, and other statements that are not tables are skipped and counted, so you know how much it passed over. Session statements such as `SET`, `USE`, `PRAGMA`, `BEGIN`, and `COMMIT` are not counted. A table it cannot read is named with the reason, and the rest of the script still imports.

A diagram holds one schema. When the script has tables in several schemas, Import SQL asks which one to import, starting with the one that holds the most tables. Same-named tables in different schemas stay apart, and names are stored in the database's own case, so importing the same script again updates the tables instead of adding copies.

## What does Schemity read from my schema?

From a live database or a SQL dump, Schemity picks up table and column definitions with their data types, primary keys, `NOT NULL` and defaults, foreign keys (with referential actions) drawn as crow's foot relationships, unique constraints, indexes, and check constraints.

## What if the database has no foreign keys?

Many real databases declare none: a dbt-built warehouse, a Rails or Django app whose keys were never created, or a schema whose keys were dropped for load performance. Schemity reads the dependencies from column names instead - `orders.user_id` points at `users` - and draws them as dashed [inferred relations](https://schemity.com/doc/virtual-relations/) that are never written back to the database. A notification tells you how many were inferred, and they can all be removed in one step.

## Can an AI agent help me make sense of a reverse-engineered schema?

Yes, and this is where it helps most. Reverse-engineering gives you every table but no structure: the layout follows foreign keys or names, while the domains the tables belong to are written down in your application code. An AI agent can read both. Schemity is a local [MCP server](https://schemity.com/doc/ai-assisted-design/), so Claude Code, Cursor, Codex, or any MCP host working in your codebase can read the schema Schemity just imported and organize the diagram for you.

## Watch: an AI agent groups a legacy database by domain

<!-- The video id here must match `video.id` in the frontmatter, which emits the VideoObject schema. -->
<div class="video-embed">
    <iframe
        src="https://www.youtube-nocookie.com/embed/Wl6g06b3Ij8"
        title="Auto-Organize a Complex Legacy Database into Meaningful Domains"
        loading="lazy"
        referrerpolicy="strict-origin-when-cross-origin"
        allow="clipboard-write; encrypted-media; picture-in-picture; web-share"
        allowfullscreen
    ></iframe>
</div>

The video runs the whole workflow on a real legacy schema in under two minutes:

1. **Connect the database.** Schemity draws every table at once, with missing foreign keys inferred and drawn dashed.
2. **Ask your agent to organize it.** From inside the codebase, ask it to group the tables into legends by domain and route the relation lines. It reads your models from the code and the schema from Schemity over MCP.
3. **Review what it did.** Every change lands as an unsaved edit in **History**, named after the agent, so a table in the wrong domain is one undo away. Legends are presentation only and never reach the database.
4. **Read the module dependencies.** Turn the legends into [context views](https://schemity.com/doc/context-views/) in one click, then open the [Context Map](https://schemity.com/doc/context-map/) to see which domains depend on which, with the foreign keys behind every arrow counted.

The agent never gets database credentials: it reads the schema Schemity already holds, and it cannot migrate anything. For the full walkthrough, see [letting an AI agent group a legacy ERD by domain](https://schemity.com/blog/reverse-engineer-legacy-database-group-by-domain/).

## What should I do after importing?

A freshly imported schema is complete but rarely tidy. Next:

1. Arrange the entities on [The ERD Canvas](https://schemity.com/doc/erd-canvas/).
2. Split a large schema into focused [Context Views](https://schemity.com/doc/context-views/), by hand or by asking an AI agent to group it as shown above.
3. Commit the JSON so the documentation is versioned - see [Version Control in Git](https://schemity.com/doc/version-control-git/).

## Why reverse-engineer a database offline?

Reverse-engineering a real database means handling a real schema. Doing it in **database design software with no cloud** means the structure of your production system is never uploaded anywhere - ideal for client work, NDA projects, and IT-approved environments. If you bring in an AI agent, the schema goes only where that agent already sends your code, or nowhere with a local model.