SQL Parser Coverage and Limitations

Reviewed by the Free ER Diagram maintainers. Last verified against the parser implementation on September 2, 2026.

Free ER Diagram uses a focused parser to extract structural information from CREATE TABLE statements. It is designed for quick schema visualization, not as a replacement for a MySQL, PostgreSQL, SQLite, SQL Server, or Oracle parser. This page describes what the current implementation recognizes so you can tell which parts of a generated diagram are reliable and which parts require a manual check.

Important: always compare the generated tables and relationships with the source DDL. A diagram can omit an engine-specific constraint without reporting a SQL error because the browser tool does not execute the statements.

Supported Statement Shape

The parser searches for CREATE TABLE blocks and separates statements at semicolons that are outside strings and parentheses. A final statement without a semicolon is also accepted. It recognizes the optional IF NOT EXISTS phrase and an optional schema or database prefix before the table name.

CREATE TABLE IF NOT EXISTS sales.orders (
  id BIGINT PRIMARY KEY,
  customer_id BIGINT NOT NULL,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (customer_id) REFERENCES customers(id)
);

In this example, the diagram table is named orders. The schema name is retained internally, while the foreign-key target is normalized to its final table name. Backticks around simple identifiers are accepted. Double quotes work for simple column definitions, but quoted identifiers containing spaces or punctuation are outside the supported identifier pattern.

Columns, Types, And Attributes

Feature	Current behavior	What to verify
Column names	Recognizes simple word identifiers, optionally wrapped in backticks or double quotes.	Rename or manually inspect identifiers containing spaces, hyphens, or escaped quote characters.
Data types	Preserves the parsed type text and recognizes common integer, text, decimal, date/time, JSON, binary, PostgreSQL, and Oracle type names.	Engine-specific multiword types, arrays, domains, and custom types may be displayed but are not semantically validated.
Nullability	Marks a column required when its definition contains NOT NULL.	Database defaults and implicit engine rules are not inferred.
Uniqueness	Recognizes inline UNIQUE and table-level UNIQUE or UNIQUE KEY lists.	Named constraints, expression indexes, partial indexes, and index sort options need manual review.
Auto-generated values	Detects AUTO_INCREMENT, AUTOINCREMENT, SERIAL, and BIGSERIAL-style declarations.	Identity clauses, sequences, generated columns, and triggers are not fully modeled.
Defaults	Extracts a quoted string or a simple word following DEFAULT.	Functions and expressions with spaces, casts, nested parentheses, or escaped strings may be incomplete.
Comments	Reads single-quoted column comments and common table COMMENT forms.	COMMENT ON statements and dialect-specific quoting are not parsed.

Primary Keys And Foreign Keys

Inline primary keys and table-level primary-key lists are recognized. For a composite primary key, each named column is marked as part of the key. Foreign keys are recognized both as table constraints and as inline REFERENCES clauses. Schema-qualified referenced tables are reduced to the table name for diagram relationships.

CREATE TABLE order_items (
  order_id BIGINT NOT NULL,
  line_number INT NOT NULL,
  product_id BIGINT NOT NULL REFERENCES products(id),
  quantity INT NOT NULL DEFAULT 1,
  PRIMARY KEY (order_id, line_number),
  FOREIGN KEY (order_id) REFERENCES orders(id)
);

The example should produce one table with a two-column primary key and relationships to products and orders. After parsing, verify that both parent tables are present and that the diagram points to the intended columns.

Composite foreign keys need special care. The current extractor can read the text inside each column list, but the relationship model treats that text as a single field rather than pairing each child column with each referenced column. Add or correct that relationship manually in the tool.

Syntax That Requires Manual Review

The following constructs are valid in one or more database engines but are not fully represented by the focused parser:

Foreign keys added later with ALTER TABLE.
CHECK constraints, exclusion constraints, deferrable constraints, and MATCH options.
Generated or computed columns and expression-based defaults.
Expression indexes, partial indexes, included columns, and index methods.
PostgreSQL arrays and user-defined domains, SQL Server bracketed identifiers, and Oracle-specific clauses.
Quoted identifiers containing whitespace or punctuation.
Relationships that exist only in application code and have no FOREIGN KEY or REFERENCES clause.
Views, materialized views, procedures, triggers, sequences, and row-level security policies.

Unsupported clauses do not necessarily prevent the surrounding table from appearing. That is why table count alone is not enough to validate a diagram. Compare key flags, relationship endpoints, nullability, and meaningful type details as separate checks.

Recommended Verification Workflow

Count the CREATE TABLE statements in the source and compare that number with the parsed table list.
Open each table and check its primary-key columns, including every member of a composite key.
Compare every FOREIGN KEY and inline REFERENCES clause with the relationship list.
Inspect nullable foreign keys because they change whether a relationship is optional.
Review UNIQUE constraints because they may change a relationship from one-to-many to one-to-one.
Add relationships implemented by application logic or ALTER TABLE statements.
Export only after labels, grouping, and relationship endpoints match the source design.

Choosing Mermaid Or PlantUML

Both output modes use the same parsed table model, so switching renderers does not recover a constraint that the parser did not extract. Mermaid is rendered in the browser. PlantUML mode may send generated diagram text to the public PlantUML rendering service. Do not place credentials, customer records, or production secrets in table names, comments, or pasted samples. For a deeper renderer comparison, read PlantUML vs Mermaid.

Reporting A Parser Issue

A useful report includes the smallest CREATE TABLE statement that reproduces the problem, the database engine and version, the expected table or relationship, and what the diagram actually shows. Remove production data and secrets first. Send reports through the contact page or open an issue in the public repository. Corrections are reviewed under the site's editorial policy.