Generate Entity-Relationship Diagrams from Text with AI
Describe your database schema in plain English. Get a valid Draw.io ERD with Crow's Foot notation, cardinality markers, and primary/foreign key labels.
This AI ERD generator converts plain-text database descriptions into Draw.io entity-relationship diagrams with Crow's Foot notation. Describe a schema like 'users have many orders, each order has many line items, each line item references a product with a price and SKU.' The AI creates entity boxes with typed attributes, marks primary keys and foreign keys, draws relationship lines with correct cardinality symbols (one-to-one, one-to-many, many-to-many with junction tables), and outputs valid mxGraphModel XML. Every entity snaps to a 10px grid. Architecture warnings flag ambiguous entities (WARN-05) that lack clear attribute definitions. VLM visual validation catches overlapping relationship lines after render. The output is native .drawio XML.
What Is an AI ERD Generator?
An entity-relationship diagram maps the tables, columns, and relationships in a database schema. Entities become boxes listing attributes with data types. Lines between entities show cardinality: one-to-one, one-to-many, or many-to-many. Crow's Foot notation uses fork symbols at line endpoints to indicate 'many' and single lines for 'one.' Building ERDs manually means creating each entity box, typing out every column and data type, drawing relationship lines, and positioning cardinality markers by hand. An AI ERD generator replaces that workflow. You describe your schema in natural language. The AI identifies entities, infers attributes and data types, determines cardinality from phrases like 'each customer has many orders,' and generates junction tables for many-to-many relationships automatically. Diagrams.so applies database-specific conventions. Primary keys get PK labels and appear at the top of each entity box. Foreign keys get FK labels with arrows pointing to the referenced table's primary key. Composite keys and unique constraints are annotated. The AI handles normalization patterns: if your description implies a many-to-many relationship between students and courses, it generates a student_courses junction table with both foreign keys and its own primary key. RULE-06 groups related entities. Tables in the same domain (users, roles, permissions) cluster together. RULE-07 labels every relationship line with its cardinality. VLM visual validation detects crossing relationship lines that make the diagram hard to read. WARN-05 flags entities named generically like 'Data' or 'Info' that need specific names. The .drawio output works in Draw.io, Confluence, and any mxGraphModel-compatible editor.
Key components
- Entity boxes with attribute lists showing column name, data type (VARCHAR(255), INTEGER, TIMESTAMP), and constraints
- Crow's Foot cardinality symbols: one (single line), many (fork), zero-or-one (circle + line), zero-or-many (circle + fork)
- Primary key (PK) labels at the top of each entity with underlined attribute names
- Foreign key (FK) labels with arrows pointing from child entity to parent entity's primary key
- Junction tables auto-generated for many-to-many relationships (e.g., student_courses, order_products)
- Unique constraint indicators (UQ) and NOT NULL markers for required columns
- Color-coded domain grouping for related entities (auth tables, billing tables, content tables)
- Relationship labels on lines describing the association (places, belongs_to, contains)
How to generate with AI
- 1
Describe your database schema
Write your schema in plain English with specific entities, attributes, and relationships. For example: 'Users table with id (UUID PK), email (VARCHAR unique), password_hash, created_at. Each user has one profile with bio and avatar_url. Users create many posts. Each post has a title, body (TEXT), published_at, and status (ENUM: draft, published, archived). Posts belong to one category. Posts have many tags through a post_tags junction table.' Include data types when you want them on the diagram.
- 2
Select diagram type and options
Choose 'ERD' as the diagram type. Diagrams.so loads entity-relationship shapes with Crow's Foot notation by default. Enable opinionated mode to enforce top-down primary-to-foreign-key layout, automatic junction table generation, and domain-based entity grouping. The AI follows RULE-06 to cluster related tables and RULE-07 to label every relationship.
- 3
Generate and refine
Click generate. The AI produces .drawio XML with entity boxes, typed attributes, PK/FK labels, and Crow's Foot relationship lines. VLM visual validation flags crossing relationship lines and overlapping entity boxes. Architecture warning WARN-05 identifies vaguely named entities. Download the .drawio file to edit in Draw.io, or export to PNG or SVG for documentation. Add missing constraints or indexes directly in the Draw.io editor.
Example prompt
E-commerce database schema. Users table: id (UUID PK), email (VARCHAR 255 UNIQUE NOT NULL), password_hash (VARCHAR 60), first_name, last_name, created_at (TIMESTAMP DEFAULT NOW). Addresses table: id (UUID PK), user_id (FK to users), street, city, state, zip_code, country, is_default (BOOLEAN). Each user has many addresses. Products table: id (UUID PK), name (VARCHAR 255), description (TEXT), price (DECIMAL 10,2), sku (VARCHAR 50 UNIQUE), stock_quantity (INTEGER DEFAULT 0), category_id (FK to categories). Categories table: id (UUID PK), name (VARCHAR 100 UNIQUE), parent_id (self-referential FK for subcategories). Orders table: id (UUID PK), user_id (FK to users), shipping_address_id (FK to addresses), status (ENUM: pending, paid, shipped, delivered, cancelled), total_amount (DECIMAL 10,2), placed_at (TIMESTAMP). Order_items junction: id (UUID PK), order_id (FK to orders), product_id (FK to products), quantity (INTEGER), unit_price (DECIMAL 10,2). Products have many tags through product_tags junction table. Tags table: id (UUID PK), name (VARCHAR 50 UNIQUE).
Example diagrams from the gallery
ERD (Crow's Foot) vs UML Class Diagram vs Database Schema Diagram
These three diagram types all describe data structures, but they target different audiences and levels of abstraction. ERDs model database-level relationships. UML class diagrams model object-oriented code. Database schema diagrams show the physical implementation with indexes and tablespaces.
| Feature | ERD (Crow's Foot) | UML Class Diagram | Database Schema Diagram |
|---|---|---|---|
| Abstraction level | Logical/conceptual: entities, attributes, and relationships without implementation details | Object-oriented: classes with methods, visibility modifiers (+/-/#), and inheritance hierarchies | Physical: tables with column types, indexes, partitions, tablespaces, and storage engines |
| Relationship notation | Crow's Foot symbols: fork for many, line for one, circle for optional (zero-or-many, zero-or-one) | Multiplicity numbers (1, 0..1, 0..*) on association lines; aggregation diamonds, composition filled diamonds | Foreign key arrows from child column to parent PK; no cardinality symbols, just FK constraints |
| Inheritance support | Not native; subtype/supertype shown with circle-and-line notation in extended ER models | First-class: hollow triangle arrowhead for generalization; interfaces with dashed arrows | Implemented as single-table inheritance, class-table inheritance, or concrete-table inheritance patterns |
| Method/behavior visibility | None. ERDs model data structure only, not behavior or operations on that data | Full method signatures with return types, parameters, and access modifiers (public, private, protected) | Stored procedures and triggers may appear as separate objects linked to tables |
| Many-to-many handling | Explicit junction table with two one-to-many relationships (users -> user_roles <- roles) | Direct many-to-many association line with 0..* on both ends; no junction class required unless it has attributes | Junction table visible with composite primary key, foreign key indexes, and additional columns if needed |
| Best suited for | Database design reviews, migration planning, schema documentation for DBAs and backend developers | Application architecture, API design, domain modeling for software engineers and architects | DBA-level physical planning: index strategy, partition schemes, replication topology |
When to use this pattern
Use an ERD when you need to design, document, or communicate a database schema. Schema design reviews before migration, new feature planning that adds tables, and onboarding documentation for backend developers are ideal use cases. ERDs work best for relational databases: PostgreSQL, MySQL, SQL Server, Oracle. If you're modeling an object-oriented codebase with inheritance and method signatures, use a UML class diagram instead. If you need to show physical storage details like indexes, partitions, and tablespace allocation, a database schema diagram is more appropriate. For NoSQL databases with flexible schemas, ERDs can still document the intended document structure, but they won't capture embedded documents or array fields natively.
Frequently asked questions
Does the AI ERD generator support Crow's Foot notation?
Yes. This AI ERD generator uses Crow's Foot notation by default. One-to-one relationships get single lines on both ends. One-to-many relationships get a single line on the parent side and a fork on the child side. Many-to-many relationships generate a junction table with two one-to-many relationships automatically.
Can I specify column data types and constraints?
Yes. Include data types in your prompt like 'email VARCHAR(255) UNIQUE NOT NULL.' The AI places the data type next to each attribute in the entity box. Primary keys get PK labels and appear first. Foreign keys get FK labels with relationship arrows. If you omit types, the AI infers reasonable defaults based on attribute names.
How does the AI handle many-to-many relationships?
When your description implies a many-to-many relationship like 'students enroll in many courses and each course has many students,' the AI automatically generates a junction table (student_courses) with foreign keys to both parent tables. The junction table gets its own primary key and any additional attributes you specify.
Can I generate ERDs from existing SQL DDL statements?
Paste your CREATE TABLE statements directly into the prompt. The AI parses table names, column definitions, PRIMARY KEY and FOREIGN KEY constraints, and UNIQUE indexes. It produces an ERD matching your existing schema exactly. This works for PostgreSQL, MySQL, and SQL Server DDL syntax.
What export formats are available for ERDs?
Native .drawio XML is the default output, which opens in Draw.io desktop, the VS Code extension, and Confluence. You can export to PNG for embedding in wiki pages or SVG for scalable documentation. Voice-to-diagram input lets you describe your schema verbally for hands-free ERD generation.
Related diagram generators
Generate UML Diagrams from Text with AI
Describe your classes, components, or deployment topology in plain English. Get a valid Draw.io UML diagram with correct UML 2.5 notation and relationships.
Generate Data Flow Diagrams from Text with AI
Describe how data moves through your system. Get a valid Draw.io DFD with Yourdon-DeMarco notation, decomposition levels, and named data flows.
Generate System Architecture Diagrams from Text
Describe your system's components in plain English. Get a valid Draw.io diagram with services, databases, message queues, caches, and API connections.
Generate Flowcharts from Text with AI
Describe a process in plain English. Get a valid Draw.io flowchart with correct ISO 5807 symbols, decision diamonds, and directional arrows.