# Import From Other Database Design Software

> Schemity imports SQL, DBML and the model files of Visual Paradigm, MySQL Workbench, Navicat and DbSchema, keeping table positions where the file stores them.

Source: https://schemity.com/doc/import-from-other-tools/

Schemity imports a schema from six kinds of file: a SQL script, DBML, and the model files of Visual Paradigm, MySQL Workbench, Navicat and DbSchema. Each import turns the file's tables into native entities, with column types written for your diagram's database, and the four model formats also keep each table's position. If the database itself is reachable, [reverse engineering](https://schemity.com/doc/reverse-engineer-database/) is usually the better start: it reads the real schema instead of a copy of it.

## Where are the import buttons?

On a new diagram's empty canvas, under **Nothing here yet**, in two rows of three: **Import SQL**, **Import DBML**, **Import Visual Paradigm**, **Import MySQL Workbench**, **Import Navicat** and **Import DbSchema**.

Import SQL is also in the control bar (`⌘⇧I`), on a diagram that already has tables; the DBML and model-file imports are offered only on an empty main diagram, since they bring in a whole model. Inside a [context view](https://schemity.com/doc/context-views/) you import entities from the main diagram instead.

## Which files can Schemity import?

| Import | File | What arrives |
|---|---|---|
| **Import SQL** | A `.sql` file, or pasted `CREATE TABLE` statements or a whole schema script | Tables, columns, keys, indexes, check constraints and comments, as the script declares them |
| **Import DBML** | A `.dbml` file, or pasted DBML, from dbdiagram.io, dbdocs or any DBML tool | `Table`, `Ref` and `Enum` definitions, check constraints, and `[increment]` on a primary key as the database's own identity |
| **Import Visual Paradigm** | A `.vpp` project, or its XML export | One ER diagram's tables with keys, indexes, checks, comments and positions |
| **Import MySQL Workbench** | A `.mwb` model | One EER diagram's tables with keys, indexes, comments, positions and colours |
| **Import Navicat** | A `.nmodel` file | One diagram's tables with keys, indexes, checks, comments, positions and colours |
| **Import DbSchema** | A `.dbs` project | One diagram's tables with keys, indexes, checks, comments, positions and colours; each DbSchema group becomes a [legend](https://schemity.com/doc/legends-and-annotations/) |

DBML and SQL store no layout, so their tables are laid out fresh. A `.mwb` model never stores a check constraint, so a MySQL Workbench import has none to bring.

## How does an import work?

You pick the file, choose what to bring in, check the preview, and import.

1. **Pick the file.** For a model file, the file picker opens first and the drawer only once a file is chosen, so a cancel leaves the screen as it was. Import SQL and Import DBML open a drawer where you paste the text or open a file.
2. **Choose the diagram.** When a project or model holds several diagrams, the drawer asks which one to import. A Navicat file can hold models for several databases, and each diagram is then labelled with its own. When a SQL script has tables in several schemas, you pick one schema, since a diagram holds one.
3. **Read the preview.** Every table is listed as New, Updated or Unchanged, and anything the import leaves out is counted underneath: DBML table groups, notes and partials; a model's views, triggers, functions and sequences; indexes and checks the diagram's database cannot express.
4. **Import.** The tables land as one step you can undo.

When Import SQL runs on a diagram that already has some of the tables, the Updated ones take the script's columns, keys and constraints and keep their position, colours and descriptions. On a connected diagram they become pending changes to the database, which you check with Preview changes before you migrate.

**Infer virtual relations from column names** is ticked by default: a column such as `user_id` gets a dashed [virtual relation](https://schemity.com/doc/virtual-relations/) to `users` where the file declares no foreign key.

## Can I import a model written for another database?

Yes: column types become your diagram's database's own, so a MySQL Workbench or Navicat MySQL model can start a PostgreSQL diagram.

What the target cannot express is left out and counted rather than written as invalid DDL. Off MySQL, for example, a prefix index becomes a plain index, a `FULLTEXT` or `SPATIAL` index is left out, and `BIT(n)` becomes `BINARY`. Defaults and generated columns survive only where they mean the same thing in the target database.

## Which versions and databases does each import read?

- **Visual Paradigm:** a `.vpp` project or its XML export. The XML export must be written with the simple structure.
- **MySQL Workbench:** `.mwb` models, with each table placed where Workbench drew it, layer offsets included.
- **Navicat:** `.nmodel` files, for MySQL, PostgreSQL, SQLite and SQL Server models. Oracle and MariaDB models are refused, and the older `.ndm2` files of Navicat Data Modeler 3 and 4 are not read; for those, export SQL from Navicat and use Import SQL.
- **DbSchema:** `.dbs` projects for PostgreSQL, MySQL, SQLite, SQL Server and Snowflake.
- **DBML:** any DBML file; table groups, notes and partials are skipped and counted.

## What about a tool not on this list?

Export SQL from it and use Import SQL: nearly every database design tool writes `CREATE TABLE` statements, and Import SQL reads PostgreSQL, MySQL, SQL Server, SQLite and Snowflake scripts. For how the competing tools compare, see [why switching database design software shouldn't mean starting over](https://schemity.com/blog/switching-erd-tools-shouldnt-mean-starting-over/).

## Do the imports need a license?

No. The imports work during the trial and in the free, design-only use after it.