Supported SQL Dialects and DDL Syntax

DDL mode’s dialect picker offers PostgreSQL, MySQL, SQL Server, SQLite, and Generic. Today, the dialect you choose is saved with the schema as descriptive metadata — it doesn’t change how the DDL is parsed. Parsing is one dialect-agnostic engine that works well across all five in practice, since standard CREATE TABLE syntax is largely shared between them. Branching parse behavior per dialect (dialect-specific type syntax, SERIAL/AUTO_INCREMENT, quoting rules) is on the roadmap but not implemented yet.

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 ("...", `...`, [...]), so names with reserved words or mixed case round-trip correctly
• 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.