How to Import SQL and Reverse-Engineer Your Database Schema

Most database design tutorials assume you are starting from scratch. But in the real world, most developers inherit an existing database. You join a company and find a MySQL database with 80 tables, no documentation, and a migration history that goes back eight years. Or you take over a client project and need to understand what you are working with before you can safely make any changes.

Reverse engineering — generating a visual ER diagram from an existing database schema — solves this problem. Instead of reading CREATE TABLE statements line by line, you import your SQL and let the tool produce a visual diagram that shows all your tables, columns, and relationships at once.

Why Reverse Engineering Matters

Documentation is almost always out of date. Wikis and README files describe the schema as it was when they were written, not as it is today. The source of truth is the database itself. By importing your actual SQL schema, you generate documentation that is guaranteed to be accurate at the moment of import.

For new team members, a visual ER diagram dramatically reduces the time needed to understand the data model. Instead of spending a week reading migration files and querying the information schema, a new developer can look at a diagram and understand the overall structure in an hour. This is one of the most immediate productivity wins from keeping a visual schema up to date.

Reverse engineering is also the first step before any major refactoring. Before you can safely move columns between tables, split a table, or add a new relationship, you need to understand every foreign key that touches the affected tables. A visual diagram surfaces these dependencies instantly — something that is extremely difficult to see by reading migration files sequentially.

What SQL Import Does in ER Flow

ER Flow's SQL import parser reads your CREATE TABLE statements and constructs a full data model: tables with their columns and types, primary keys, foreign keys with their referenced tables and cascade rules, unique constraints, and indexes. It then renders the result as an interactive ER diagram on the canvas.

The parser understands the nuances of different SQL dialects. PostgreSQL uses SERIAL and BIGSERIAL for auto-increment; MySQL uses AUTO_INCREMENT; SQLite uses INTEGER PRIMARY KEY. ER Flow normalizes these into a unified representation, so your diagram is accurate regardless of which database engine the SQL was written for.

Step-by-Step: Importing SQL into ER Flow

Start by exporting your schema from your database. In PostgreSQL, run pg_dump --schema-only -d your_database > schema.sql. In MySQL, run mysqldump --no-data your_database > schema.sql. In SQLite, open the database with sqlite3 your.db and run .schema to print the schema, then redirect it to a file. Open ER Flow and create a new project, or open an existing one where you want to import the schema.

Click Import SQL in the toolbar. Paste your SQL directly into the text area, or upload the .sql file. Select the source dialect (PostgreSQL, MySQL, or SQLite) so the parser applies the correct rules for type normalization and constraint syntax. Click Import. Within a few seconds, your tables appear on the canvas. ER Flow auto-layouts the diagram to minimize crossing relationship lines, giving you a readable starting point.

Supported SQL Dialects

PostgreSQL support includes CREATE TABLE, CREATE INDEX, ALTER TABLE ADD CONSTRAINT FOREIGN KEY, sequences, SERIAL/BIGSERIAL/UUID primary key types, array types, and JSONB/JSON columns. MySQL support includes CREATE TABLE with ENGINE=InnoDB, inline FOREIGN KEY definitions, AUTO_INCREMENT, ENUM types, and UNSIGNED modifiers. SQLite support covers CREATE TABLE with PRIMARY KEY and FOREIGN KEY references in the standard SQLite syntax.

The parser intentionally skips DDL that does not affect the schema structure — INSERT statements, GRANT and REVOKE permissions, database-level settings, comments, and stored procedures. It focuses on the structural definition that belongs in the ER diagram. If your SQL file includes stored procedures or triggers that you want to model, ER Flow supports adding these manually after the initial import.

Common Import Issues and How to Fix Them

Foreign keys not appearing: This usually means the FK constraints were defined with ALTER TABLE statements that come after the table creation, and the referenced tables were not yet parsed when the constraint was encountered. Solution: ensure your SQL file exports all CREATE TABLE statements before any ALTER TABLE statements, or use ER Flow's manual relationship tool to draw the missing FKs after import.

Unknown types: If you use custom PostgreSQL types — enums, domains, composite types — or database-specific spatial types like GEOMETRY, the parser may not recognize them. ER Flow renders these columns with a custom type indicator. You can manually update the type display after import, or add a note explaining the custom type. Large schemas: If your schema has more than 200 tables, the initial layout may take a few seconds longer. For very large schemas, consider importing in logical groups — core entity tables first, then reference tables, then analytics tables — so each group can be laid out and organized before the next is added.

What to Do After Import

The generated diagram is a starting point, not a finished product. After import, invest time in three activities. First, clean up the layout — drag tables into logical groupings (auth tables together, order processing tables together, analytics tables together). Good spatial organization communicates architectural intent as clearly as the relationships themselves.

Second, identify and plan technical debt — the visual diagram often reveals problems that are invisible in the SQL: tables with no primary key, foreign key columns without indexes, columns with names that suggest they belong to a different entity, or junction tables that are missing one of their foreign keys. Document these findings using ER Flow's note tool, then create a checkpoint and use the migration generator to plan the refactoring work as incremental, reviewable migrations.

Third, share the diagram with your team. ER Flow's real-time collaboration means your entire team can view the imported schema simultaneously. Use the diagram as the foundation for a design review session: is this the schema we want to build on, or should we discuss refactoring before adding new features? Starting that conversation with a shared visual diagram is far more productive than reviewing SQL diffs.