ERD Generator: Build Entity Relationship Diagrams with AI
TalkingSchema is an AI-powered ERD generator and entity relationship diagram tool built for database engineers, software architects, and data teams who need to move from requirements to a production-ready schema without the manual overhead of traditional diagramming tools. Describe your system in plain language, import an existing database, or start from a template — TalkingSchema's AI copilot generates the ERD, proposes every change through an approval checklist, and displays a precise diff on the canvas before a single line of schema is committed.
Free to start. No installation. Works in any modern browser.
What Is an Entity Relationship Diagram?
An Entity Relationship Diagram (ERD) is the authoritative visual contract of a database schema. It defines every table (entity), every column (attribute), every constraint, and every foreign key relationship in a single navigable view. In a well-maintained engineering organization, the ERD is the first artifact a new engineer consults and the last artifact a database administrator updates before a production deploy.
A complete ERD encodes:
- Entities — tables, their columns, data types, and nullability
- Relationships — foreign key constraints, cardinality (one-to-one, one-to-many, many-to-many), and cascade behavior
- Integrity constraints — primary keys, unique constraints, check constraints, and indexes
- Domain rules — enum types, default values, computed columns
Without an ERD, schema decisions live in the heads of individual contributors. With one, they become auditable, reviewable, and shareable across every team that touches data.
How TalkingSchema Generates ERDs
TalkingSchema uses a conversational AI copilot with persistent schema context to generate and evolve ERDs through natural language dialogue — not one-shot prompt-to-diagram translation.
Step 1 — Describe your system
Tell the AI copilot what you are building. Be as specific or as general as your current requirements allow:
"Design a 3NF transactional schema for a global supply chain system. Include suppliers, products with carbon intensity scoring, warehouses, purchase orders, sales orders, and shipment tracking. Use snake_case naming and include audit columns on every table."
The AI interprets domain intent, applies relational database best practices (normalization, referential integrity, appropriate index candidates), and produces a structured schema plan.
Step 2 — Review the Plan
Before any table is drawn, TalkingSchema presents a structured checklist of every proposed change — each create, alter, or drop as a line item. Per-item inline editing of the checklist coming soon. User will be able to approve individual items or reject specific changes before a single line of schema is committed. This is the critical difference between an AI assistant and an AI partner: you remain the architect.
Step 3 — Apply and inspect the diff
Once approved, changes are applied to the canvas and highlighted with a color-coded diff layer: green for additions, amber for modifications, red for removals. The canvas shows precisely what changed in this iteration. Click Keep all to commit, or Undo all to revert — full version safety at every step.
Step 4 — Iterate
Ask the AI to refine the schema in natural language: "Add a many-to-many relationship between products and certifications," or "The shipments table should track CO₂ emissions per carrier leg." Each iteration goes through the same checklist → diff → keep/undo cycle.
Example: Global Supply Chain ERD
The following schema represents a normalized 3NF transactional model for a sustainable global supply chain — a domain complex enough to illustrate realistic ERD patterns including multi-level foreign key hierarchies, junction tables, and audit columns.
-- Core entities for a Global Sustainable Supply Chain (GSSC)
CREATE TABLE suppliers (
supplier_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
company_name VARCHAR(200) NOT NULL,
country VARCHAR(100) NOT NULL,
carbon_tier VARCHAR(10) CHECK (carbon_tier IN ('A', 'B', 'C', 'D')) NOT NULL,
certification VARCHAR(100),
is_active BOOLEAN DEFAULT TRUE,
created_at TIMESTAMPTZ DEFAULT now(),
updated_at TIMESTAMPTZ DEFAULT now()
);
CREATE TABLE products (
product_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
sku VARCHAR(50) UNIQUE NOT NULL,
name VARCHAR(200) NOT NULL,
category VARCHAR(100) NOT NULL,
unit_weight_kg DECIMAL(8,3),
unit_cost_usd DECIMAL(12,4) NOT NULL,
carbon_intensity_score DECIMAL(5,2), -- kg CO₂ per unit
supplier_id UUID NOT NULL REFERENCES suppliers(supplier_id),
is_active BOOLEAN DEFAULT TRUE,
created_at TIMESTAMPTZ DEFAULT now(),
updated_at TIMESTAMPTZ DEFAULT now()
);
CREATE TABLE warehouses (
warehouse_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
name VARCHAR(200) NOT NULL,
location_city VARCHAR(100) NOT NULL,
location_country VARCHAR(100) NOT NULL,
capacity_units INTEGER NOT NULL,
is_active BOOLEAN DEFAULT TRUE
);
CREATE TABLE customers (
customer_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
company_name VARCHAR(200) NOT NULL,
country VARCHAR(100) NOT NULL,
tier VARCHAR(20) CHECK (tier IN ('enterprise', 'mid-market', 'smb')) NOT NULL,
credit_limit_usd DECIMAL(14,2) DEFAULT 0,
created_at TIMESTAMPTZ DEFAULT now()
);
CREATE TABLE purchase_orders (
po_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
supplier_id UUID NOT NULL REFERENCES suppliers(supplier_id),
warehouse_id UUID NOT NULL REFERENCES warehouses(warehouse_id),
order_date DATE NOT NULL,
expected_delivery DATE,
status VARCHAR(30) CHECK (status IN ('draft','confirmed','shipped','received','cancelled')),
created_at TIMESTAMPTZ DEFAULT now(),
updated_at TIMESTAMPTZ DEFAULT now()
);
CREATE TABLE purchase_order_items (
item_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
po_id UUID NOT NULL REFERENCES purchase_orders(po_id) ON DELETE CASCADE,
product_id UUID NOT NULL REFERENCES products(product_id),
quantity INTEGER NOT NULL CHECK (quantity > 0),
unit_cost_usd DECIMAL(12,4) NOT NULL
);
CREATE TABLE shipments (
shipment_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
po_id UUID NOT NULL REFERENCES purchase_orders(po_id),
warehouse_id UUID NOT NULL REFERENCES warehouses(warehouse_id),
carrier VARCHAR(100),
shipped_at TIMESTAMPTZ,
arrived_at TIMESTAMPTZ,
co2_kg DECIMAL(10,3), -- actual carbon per shipment leg
created_at TIMESTAMPTZ DEFAULT now()
);
CREATE TABLE sales_orders (
so_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
customer_id UUID NOT NULL REFERENCES customers(customer_id),
warehouse_id UUID NOT NULL REFERENCES warehouses(warehouse_id),
order_date DATE NOT NULL,
status VARCHAR(30) CHECK (status IN ('pending','confirmed','shipped','delivered','cancelled')),
payment_terms VARCHAR(50),
created_at TIMESTAMPTZ DEFAULT now(),
updated_at TIMESTAMPTZ DEFAULT now()
);
CREATE TABLE sales_order_items (
item_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
so_id UUID NOT NULL REFERENCES sales_orders(so_id) ON DELETE CASCADE,
product_id UUID NOT NULL REFERENCES products(product_id),
quantity INTEGER NOT NULL CHECK (quantity > 0),
unit_price_usd DECIMAL(12,4) NOT NULL
);
CREATE TABLE inventory (
inventory_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
warehouse_id UUID NOT NULL REFERENCES warehouses(warehouse_id),
product_id UUID NOT NULL REFERENCES products(product_id),
quantity_on_hand INTEGER NOT NULL DEFAULT 0,
reorder_point INTEGER NOT NULL DEFAULT 0,
last_counted_at TIMESTAMPTZ,
UNIQUE (warehouse_id, product_id)
);
This schema is used as a consistent reference example throughout the TalkingSchema documentation. Paste this DDL into TalkingSchema to generate the ERD instantly, then explore the AI-driven workflows described in the subsequent sections.
Canvas Editing: Direct Diagram Interaction
TalkingSchema provides a fully interactive ERD canvas — not a read-only visualization of code elsewhere. Every table, column, relationship, and constraint is editable directly in the diagram.
What you can do on the canvas
| Action | How |
|---|---|
| Create a new table | Drag from the toolbar onto the canvas, or ask the AI |
| Add a column | Click the + row inside any table node |
| Edit column name or type | Double-click any field in the table node |
| Draw a relationship | Hover a table edge until the connector handle appears, then drag to the target table |
| Reposition tables | Drag by the table header |
| Auto-layout | Click the ELK layout button — minimizes edge crossings and groups related tables |
| Toggle table visibility | Use the visibility panel to focus on a schema subset |
| Zoom and pan | Scroll wheel to zoom; click-drag on empty canvas to pan |
Draw Mode vs. Plan Mode
Two editing modes serve different workflow needs:
Draw Mode — changes are applied to the ERD canvas immediately as the AI generates them. Optimized for rapid prototyping where speed of iteration matters more than step-by-step review.
Plan Mode (recommended for production schemas) — the AI first presents a structured checklist of every proposed operation. You review, approve or exclude individual items, then execute. After execution, the canvas displays a change diff. This mode prevents unintended schema modifications and creates a natural review checkpoint in collaborative environments.
Import: Start from What You Already Have
If your database already exists, there is no reason to redraw it from scratch.
Supported import methods
| Method | Best for |
|---|---|
| Connect to live database | Supabase or Neon — reverse-engineer your current production schema |
| Upload SQL file | DDL dumps, Flyway/Liquibase migration files, pg_dump output |
| Paste SQL | Quick visualization from clipboard |
| Upload DBML file | Import from any DBML-formatted schema |
| Natural language import | Describe an existing system and let the AI reconstruct it (coming soon) |
After import, the full ERD is rendered on the canvas — including all foreign key relationships, constraints, and enum types — ready for AI-assisted analysis, refactoring, or export.
Export: Every Format Your Workflow Needs
TalkingSchema exports your ERD and underlying schema in every format your development workflow requires. Standard exports are available from the Export button in the top toolbar. Framework-specific and specialized outputs are generated by the AI copilot inside the conversation.
| Format | Output |
|---|---|
| SQL DDL | CREATE TABLE statements for PostgreSQL, MySQL, SQLite, MSSQL |
| DBML | Database Markup Language for schema-as-code workflows |
| JSON | Full schema model for programmatic processing and CI/CD pipelines |
| PNG / SVG / PDF | High-resolution ERD images for documentation, Confluence, Notion, and presentations |
| Prisma schema | schema.prisma with models, relations, and enums |
| Drizzle ORM | TypeScript table definitions |
| Zod validators | Runtime type-safe TypeScript schemas |
| OpenAPI spec | REST API endpoint definitions inferred from schema |
| GraphQL SDL | Type definitions and resolver signatures |
| Migration scripts | Flyway and Liquibase-compatible change scripts |
Learn more about all export formats →
Share Your ERD with Anyone
Every schema in TalkingSchema can be shared as a read-only public link with no account required for the viewer. Use it to share a schema for pull request review, include it in a technical design document, or embed an ERD image in Confluence or Notion.
Frequently Asked Questions
Can I use TalkingSchema as a free ER diagram tool?
Yes. The Hobby plan is permanently free and includes full ERD generation, canvas editing, AI copilot access, SQL/DBML/JSON export, and public share links. No credit card is required.
Does TalkingSchema work for large schemas with 100+ tables?
Yes. TalkingSchema uses the ELK (Eclipse Layout Kernel) layout engine to automatically arrange large schemas, minimizing edge crossings and grouping related tables. The node visibility panel lets you focus on specific subsystems without removing tables from the model.
Can multiple team members edit the same ERD?
Real-time collaborative editing is on the roadmap. Currently, the most effective team workflow is to share a public link for review, and use the AI-powered change checklist to communicate proposed modifications clearly before applying them.
What databases are supported?
For import via live connection: Supabase (PostgreSQL) and Neon (PostgreSQL). For SQL file import and paste: PostgreSQL, MySQL, SQLite, and MSSQL DDL syntax. For export: PostgreSQL, MySQL, SQLite, and MSSQL.
Is my schema data secure?
TalkingSchema does not store your database content — only the schema structure (table names, column names, types, constraints). Connection credentials for live database imports are not persisted after the session. All infrastructure subprocessors are SOC 2, GDPR, and CCPA compliant.