Supported SQL Dialects and DDL Syntax

DDL mode’s dialect picker offers PostgreSQL, MySQL, SQL Server, SQLite, and Generic. The dialect you choose is saved with the schema and used to correctly detect auto-incrementing columns — Postgres SERIAL/BIGSERIAL/SMALLSERIAL and GENERATED ... AS IDENTITY, MySQL AUTO_INCREMENT, SQL Server IDENTITY(seed, increment), and SQLite’s implicit INTEGER PRIMARY KEY rowid-alias behavior or an explicit AUTOINCREMENT keyword. Picking Generic recognizes any of these patterns, which is the safest choice if you’re not sure or your DDL mixes conventions. Everything else about parsing — table/column/constraint structure — is one shared engine across all five, since standard CREATE TABLE syntax is largely the same between them.

What gets parsed

• CREATE TABLE statements: column names and types, PRIMARY KEY (both inline on a column and as a table-level constraint), FOREIGN KEY ... REFERENCES (inline and table-level), UNIQUE, and NOT NULL
• Standalone CREATE [UNIQUE] INDEX ... ON table (cols) statements — these attach to the matching table automatically rather than needing to be inline
• Quoted and bracketed identifiers ("...", `...`, [...]) in any style regardless of the selected dialect, so names with reserved words or mixed case round-trip correctly — including SQL Server’s [bracket] style, which is recognized everywhere a table or column name can appear, not just inside a column definition
• Schema-qualified names (dbo.Users, [dbo].[Users], "public"."users") — the schema prefix is dropped and only the bare table name is kept, so a schema-qualified CREATE TABLE still links up with a schema-qualified REFERENCES elsewhere in the same DDL
• Comments (-- ... and /* ... */), which are stripped before parsing
• Paren-depth-aware comma splitting, so a type like NUMERIC(10,2) isn’t incorrectly split into two columns
• Tables with colliding names are deduplicated rather than producing duplicate nodes

Practical tips

• A plain pg_dump --schema-only, a Prisma/Drizzle-generated migration’s raw SQL, or a hand-written schema file all parse the same way — there’s no special export format required.
• If a table or relationship doesn’t show up as expected, check the DDL for a FOREIGN KEY that doesn’t resolve to a matching CREATE TABLE name — the parser links FKs by table name match.
• Even without an explicit FK, a column like user_id will usually be picked up as an inferred relationship to a users/user table by naming convention — see Reading the ERD Diagram for how that’s shown differently from a real FK.