AI Assist

Talk to ERD Designer and its AI will create your model

Every tool now says it has AI, but Artificial Intelligence is built into ERD Designer. In addition to enabling you to diagram manually, you can speak to ERD Designer and watch while it updates your ERD in real-time.

ERD Designer's AI Assist can interview a business owner and model what is known about the business. The more you know about your business, the more advanced the resulting model will be. Even veteran data-scientists rave about this feature. Give it a try!

Try it FREE NOW!

Contact, Customer and the associative entity Customer_Contact_Assignment between them, built by two spoken requests

Open AI Assist from the Ai icon in the toolbar.Press Start AI Assist, then type — or press Speak.Wait… turns to Talk… when the microphone is live.Say what you want. Nothing is sent until you press Send.Customer is on the diagram, exactly as asked.Link customers to contacts with an associative entity.Two sentences, three entities, both relationships.2 requests · 3 entities

Watch while Artificial Intelligence:

Adds new entities
Adds new attributes
Sets datatypes
Creates Super-types
Moves sub-types in or out of super-types
Creates relationships between entities
Changes entity names

Whatever you want to do, ERD Designer's AI Assist can do it.

AI Access is a one-time unlock with 100 assists included. Top-up packs never expire. There is no second subscription, and a retry of a failed turn is free.

Browser-based Entity Relationship Diagramming for Professionals.

Bring your DDL schema, and get a diagram you can actually read.

87% of data architects prefer the way our algorithms organize a diagram over their own manual attempts.

The imported schema on the canvas: fifteen tables in colour-banded rows, every foreign key a vertical line

Start from the welcome screen and choose Import DDL.Pick a database the Agent on this computer can reach.Pick the schema. The Agent reads it; the app never sees a credential.Fifteen tables, laid out with every relationship straight.Up close: keys, nullability and types on every table, and not one bent line.15 tables · 0 bends

Three tools, one canvas

Most professionals come here seeking:

Import

You already have a database schema, but you need a diagram you can read.

Paste DDL or read a live database. Even sophisticated schemas become beautiful diagrams when imported into ERD Designer. We built this product to manage an ERD the way we would want. And you benefit!

See how our algorithms organize your complicated schema.

If an ERD tool can't organize your schema, then what's the point?

Model

Logical entities are transformed into a physical schema for your target database.

Model conceptually with Entities, SuperTypes, and SubTypes, then watch while ERD Designer transforms your logical model into a physical schema. Better yet, allow AI Assist to interview you and watch while it builds an ERD right before your eyes.

See the transformation Generate

Watch while your diagram is transformed into an operational database.

The best part about a great ERD tool is the ease with which it transforms your diagram into a working database. ERD Designer auto-generates the DDL, or it can connect to your database and deploy your schema. You are in control.

See the results

Import

Try ERD Designer NOW!

Paste your DDL here
then see it in action.

Paste the CREATE TABLE statements from PostgreSQL, Oracle, SQL Server, MySQL, MariaDB, SQLite, Amazon Redshift, Google BigQuery or Snowflake and open them in ERD Designer, laid out and ready to edit.

You will sign up free with Google, Microsoft or your email address, and land on your diagram. Every account starts on the FREE Basic plan. You may use it without providing any payment information.

DDL script

Paste your DDL into the below text area and see it in ERD Designer - NOW!

-- ERD DDL engine 1.0.0 · PostgreSQL 17 · 2026-10-05
-- Do not delete this line: ddl-apply reads it to check that the tool
-- applying this script understands it the same way the app that wrote it did.

-- Create table Contact
CREATE TABLE "public"."Contact" (
  "id" SERIAL NOT NULL,
  "name" VARCHAR(100) NOT NULL,
  "description" VARCHAR(255),
  "created_date" DATE NOT NULL,
  CONSTRAINT "Contact_pkey" PRIMARY KEY ("id")
);

-- Create table Contact_Customer
CREATE TABLE "public"."Contact_Customer" (
  "contact_id" INTEGER NOT NULL,
  "customer_id" INTEGER NOT NULL,
  "created_date" TIMESTAMP NOT NULL DEFAULT now(),
  CONSTRAINT "Contact_Customer_pkey" PRIMARY KEY ("contact_id", "customer_id")
);

-- Create table Customer
CREATE TABLE "public"."Customer" (
  "id" SERIAL NOT NULL,
  "name" VARCHAR(100) NOT NULL,
  "email" VARCHAR(255),
  "phone_number" NUMERIC(10,0),
  "status_id" INTEGER NOT NULL,
  CONSTRAINT "Customer_pkey" PRIMARY KEY ("id")
);

-- Create table Customer_Statuses
CREATE TABLE "public"."Customer_Statuses" (
  "id" SERIAL NOT NULL,
  "status_code" VARCHAR(20) NOT NULL,
  "status_description" VARCHAR(50),
  CONSTRAINT "Customer_Statuses_pkey" PRIMARY KEY ("id")
);

-- Add unique constraint on Customer_Statuses (status_code)
ALTER TABLE "public"."Customer_Statuses" ADD CONSTRAINT "Customer_Statuses_status_code_key" UNIQUE ("status_code");

-- Add foreign key Contact_Customer (contact_id) → Contact (id)
ALTER TABLE "public"."Contact_Customer" ADD CONSTRAINT "Contact_Customer_contact_id_fkey" FOREIGN KEY ("contact_id") REFERENCES "public"."Contact" ("id");

-- Add foreign key Contact_Customer (customer_id) → Customer (id)
ALTER TABLE "public"."Contact_Customer" ADD CONSTRAINT "Contact_Customer_customer_id_fkey" FOREIGN KEY ("customer_id") REFERENCES "public"."Customer" ("id");

-- Add foreign key Customer (status_id) → Customer_Statuses (id)
ALTER TABLE "public"."Customer" ADD CONSTRAINT "Customer_status_id_fkey" FOREIGN KEY ("status_id") REFERENCES "public"."Customer_Statuses" ("id");

CREATE TABLE, ALTER TABLE ADD CONSTRAINT and CREATE INDEX are read. Up to 2 MB.

Source database

Diagram name (optional)

Held for 15 minutes, and deleted from our server the moment you open it.

Model

Super-Types at a glance

Data scientists often need to abstract multiple entities during implementation.

As an example, let’s say that you own a pet shop. Your customers walk into your store where you sell product to them. But, you also have customers who order products online. A sale has certain attributes that online orders do not have. For example, both sales and orders have customer and transaction date/time, but an order has a ship-to address that is irrelevant for a sale. But, when you make an in-store sale, you like to get the customer’s pet’s name and a phone number to call if you need to reach the person, and this information just isn’t practical to obtain online.

ERD DesignerThe logical modelSuper-type over Sales and Orders

Step 1 of 7: Super-type over Sales and Orders

Step 2 of 7: One table for both kinds of transaction

Step 4 of 7: Logical · two Super-types added

Step 5 of 7: Logical · Transactions stretched

Step 7 of 7: Logical · Transaction_Items stretched

Step 1 of 7

Consequently, on your logical model you use a Super-type to model your sales or orders.

But, when it comes time to implement these two types of transactions, you want them abstracted into one table.

It is standard for data-scientists to maintain both a logical and physical model and to choose to use abstraction, or not to use it. ERD Designer makes this possible. But the question is how easy is it to do this on the logical diagrammer in ERD Designer? Well, let me show you.

In the above logical diagram we have Customers. Customers can purchase product in the store (Sales) or online (Orders). Sales have one or more Products called Sale_Items, and Orders have one or more Products called Order_Items. But given that these tables are very similar, I have decided to abstract them into one table each.

In the above image I have created two super-type entities (Transactions and Transaction_Items), and both have surrogate keys. You may also notice that I have added a transaction_date_time attribute to the Transactions entity as I do not have this attribute in either the Sales or Orders tables and I need to track the date of both.

Now, watch what happens when I expand the grouping perimeter of the Transactions Super-Type to enclose Sales and Orders.

First, I enclosed Sales and Orders by simply stretching Transactions to encompass both tables. When I did this two things happened automatically. First, you may notice that a common attribute (total_amount_usd) that both Sales and Orders shared was moved to Transactions. Second, notice now that instead of both Sales and Orders having a relationship with Customers, now only the super-type (Transactions) has the relationship.

A little rearranging makes everything look nice. But, you may notice that we now need to do the same thing with Sale_Items and Order_Items. A stretch of Transaction_Items and a little rearranging does the trick.

A generation of the logical to physical model can implement this in one of two ways, both optional to the user. The sub-types can each be their own physical table each inheriting attributes from the super-type, or, the super-type can be implemented into one table with all the attributes from each sub-type. The user may select which implementation he/she desires for each super-type on the diagram.

Generate

Generate your database schema from your physical diagram.

ERD DesignerGenerated DDL48 statements for PostgreSQL · schema public

Which script do you want?

Run the full scriptApply differences only (needs a database)

Database

PostgreSQLlocalhost

Schema

public15 tables

-- Create table categories
CREATE TABLE "public"."categories" (
  "category_id" SERIAL NOT NULL,
  "parent_category_id" INT,
  "category_name" VARCHAR(100) NOT NULL,
  CONSTRAINT "categories_pkey" PRIMARY KEY ("category_id")
);
-- Create table certificates
CREATE TABLE "public"."certificates" (
  "certificate_id" SERIAL NOT NULL,
  "certificate_uuid" UUID NOT NULL,
  "issued_at" TIMESTAMP DEFAULT CURRENT_TIMESTAMP,

48 statements will run in one transaction.

Diagram

SQLgenerated

Live databaseexecuted

Diagramread back

✓48 statements executed on PostgreSQL 16

✓schema introspected: 15 tables, 21 foreign keys, 9 checks

✓0 differences — and a second run plans 0 statements

What a dialect cannot express is refused with a reason, never rendered as SQL that fails on the server.

Compatibility

Compatible with your database

Import, Model, and Generate scripts to/from your database.

To read from or apply to a live database on your own computer or network, use the ERD Designer Agent.

Pricing

Start free with the Basic Plan. Upgrade to Pro or Advanced when you need more.

Features	Basic	Pro	Advanced
Physical Data Model Diagrams (PDM)	✓	✓	✓
Save Diagrams	✓	✓	✓
Open Diagrams	✓last 72 hours	✓	✓
Export Diagrams & Reports as a PDF	—	✓	✓
Print Diagrams	—	✓	✓
Import Data Definition Language (DDL)	✓	✓	✓
Export Data Definition Language (DDL)	—	✓	✓
Forward and Reverse Database Engineering	—	✓	✓
Deploy schemas directly to Oracle, MySQL, PostgreSQL, MariaDB, SQL Server, SQLite, Redshift, BigQuery, Snowflake	—	✓	✓
Auto-conversion from one database type to another	—	✓	✓
Logical Entity Relationship Diagrams (ERD)	—	—	✓
Auto-generate Physical Data Models (PDM) from your Logical Entity Relationship Diagrams (ERD)	—	—	✓
Support for database Types and Domains	—	—	✓
Multi-Nomenclature Support	✓	✓	✓
Allow Claude and ChatGPT MCP access & AI chat.	✓	✓	✓
Retention Policy	Diagrams deleted after 30 days	Diagrams deleted three days after subscription terminates.	Diagrams deleted three days after subscription terminates.
Monthly Rate	Free	$9.99	$19.99

On Basic, the application lists and opens only diagrams saved in the last 72 hours, and permanently deletes a diagram that has not been saved for 30 days. A move to a lower plan permanently deletes, three days after it takes effect, the diagrams that plan does not include. See the Terms of Service.