Prisma to ERD guide

See the structure of your Prisma schema

Paste schema.prisma into the editor to visualize models, scalar fields, keys, enums, indexes, and relations. Conversion runs in the browser and retains readable models when diagnostics need attention.

This tool visualizes your schema. It does not connect to your datasource, run Prisma Client, or apply migrations.

The examples use Prisma 6 datasource syntax. In Prisma 7, keep the provider in schema.prisma and configure the connection URL in prisma.config.ts. Erd Go accepts a provider-only datasource; paste the schema here, not your config file or credentials.

Paste a connected schema

1. Open Prisma to ERD and choose a sample or an empty document.
2. Paste the schema below, or your own complete schema.prisma. The datasource provider controls connector-specific validation.
3. Review the diagram and diagnostics, then inspect models, fields, and relations in the explorer. Use layout controls to arrange the diagram.

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model User {
  id    Int    @id @default(autoincrement())
  email String @unique
  posts Post[]
}

model Post {
  id       Int    @id @default(autoincrement())
  title    String
  authorId Int
  author   User   @relation(fields: [authorId], references: [id])

  @@index([authorId])
}

Models, fields & mapped names

Relations & key rules

An explicit relation uses a relation field, scalar foreign-key fields, and @relation(fields: [...], references: [...]). Include an opposite relation field on the other model. Reference a primary key or globally unique key with compatible scalar and native types.

If any foreign-key scalar is optional, its owning relation field must also be optional. An optional relation may have required scalars. A one-to-one owner needs @unique or @@unique on its foreign-key fields, and the inverse field without those scalars must be optional.

Use the same quoted relation name on both sides to distinguish multiple links between the same models or a self relation. Names may contain punctuation. Field names and key references are case-sensitive; list each key field once and include every compound-key member.

Implicit relational many-to-many edges require one scalar field-level @id on each participating model. Composite, block-level, or unique-only identifiers produce a diagnostic rather than a misleading virtual relationship. Use an explicit join model for additional fields, complex keys, or referential actions.

model Profile {
  id     Int  @id @default(autoincrement())
  userId Int  @unique
  user   User @relation(fields: [userId], references: [id])
}

model User {
  id      Int      @id @default(autoincrement())
  profile Profile?
}

Enums, composite keys & database mappings

Use @@id and @@unique for multi-column keys, @map for field names, and @@map for table names. For a compatible multi-schema provider, list schemas in the datasource and assign models with @@schema. The model name remains useful in the editor while the mapped identity is preserved for database output.

The PostgreSQL example below has a composite primary key and a tenant-scoped unique email. An explicit relation to this key must supply tenantId and accountId in the same order with compatible field types.

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
  schemas  = ["identity"]
}

enum AccountState {
  ACTIVE
  DISABLED

  @@schema("identity")
}

model Account {
  tenantId  Int          @map("tenant_id")
  accountId Int          @map("account_id")
  email     String
  state     AccountState @default(ACTIVE)

  @@id([tenantId, accountId])
  @@unique([tenantId, email])
  @@map("accounts")
  @@schema("identity")
}

Providers & recoverable diagnostics

Supported datasource providers include PostgreSQL, MySQL, SQLite, SQL Server, MongoDB, and CockroachDB. The converter checks connector-specific identities, native types, defaults, relation rules, and mapped-name collisions.

Relational providers default to relationMode = "foreignKeys". MongoDB uses relationMode = "prisma" and validates its _id mapping and ObjectId requirements. Do not assume a relational example can be copied unchanged to MongoDB.

Fix missing opposite relation fields, incompatible foreign-key types, invalid key targets, and unsupported provider combinations using the diagnostics. Invalid-but-readable fields remain visible so you can repair the schema in place.

Explore, export & save

1. Search the explorer by model, field, mapped name, enum, or relation. Select a relation to review its fields, references, cardinality, and referential actions in Relation Inspector; focus either endpoint from there.
2. Use diagnostic locations to jump to the source requiring attention. Adjust layout and display preferences on the ERD.
3. Export the diagram as PNG, image-backed SVG, or PDF for a document or presentation.
4. Sign in to save a Prisma file with its source and renderer context. Save edits before sharing a read-only public link. A shared viewer does not receive source editing access.

Troubleshoot a Prisma schema

Generate Prisma with the right provider

Copy this guide as an AI prompt, name your Prisma version and provider, then state your models and business rules. Ask the assistant to preserve existing @map and @@map names while changing the schema.

Paste the returned Prisma into the editor and review diagnostics before using it elsewhere. A rendered diagram does not replace provider validation or a migration review.

Generate a PostgreSQL Prisma schema for User, Project, and Membership.
Use an explicit Membership join model with a composite key.
Include both sides of every relation and compatible foreign-key types.
Preserve these database table names: users, projects, memberships.