From Prisma Schema to ERD: A Complete Guide
A Prisma schema is already a precise data model in text. This guide shows how to read its models and relations and turn them into a clear entity relationship diagram.
If your application uses Prisma, you already have a complete, precise data model written in the schema.prisma file, and turning it into an ERD is largely a matter of translation. A visual diagram is invaluable for onboarding, design reviews, and spotting structural issues that are easy to miss when reading a long schema file top to bottom. The good news is that Prisma's schema language maps cleanly onto ERD concepts: models are entities, fields are attributes, and relation fields are the relationships.
This guide walks through reading a Prisma schema and mapping each construct to its diagram equivalent, including the sometimes-confusing relation syntax and how to spot the different cardinalities. You can build the resulting diagram in the editor at /diagrams or the ERD tooling at /diagram-tools/erd-tool, and generate a first draft from a description with the AI generator at /diagram-tools/ai-diagram-generator.
Models become entities
Each Prisma model becomes an entity in your ERD. A model declaration names the entity and lists its fields, which become the entity's attributes. Consider this model: `model User { id Int @id @default(autoincrement()) email String @unique name String? posts Post[] }` The User model becomes a User entity. The id field, marked @id, is the primary key. The email field, marked @unique, is a natural key. The name field, typed String? with the question mark, is an optional (nullable) attribute. The posts field is not a stored column at all; it is a relation, which we handle separately.
Reading a model, you translate scalar fields directly into attributes with their types, and note the attribute-level markers. The @id attribute identifies the primary key, @unique marks natural keys, and the trailing question mark on a type (String?) marks a nullable field, while its absence means the field is required. The @default annotations tell you default values but do not change the diagram structure. Keeping these markers on your ERD, primary key, unique, nullable, makes it a faithful representation rather than a lossy sketch.
Relation fields become relationships
The relationships between entities live in Prisma's relation fields, which come in pairs: each side of a relationship declares a field referring to the other model. A one-to-many relationship looks like this across two models: User has `posts Post[]` and Post has `author User @relation(fields: [authorId], references: [id])` plus `authorId Int`. The list type (Post[]) is the "many" side, and the singular type with the @relation attribute and a foreign key field (authorId) is the "one" side. This is a one-to-many from User to Post, drawn with a crow's foot on the Post end.
The key to reading Prisma relations is spotting where the foreign key lives, which is always the side with the @relation attribute naming a fields and references pair. That side is the "many" side of a one-to-many, or either side of a one-to-one. A field typed as a list (Model[]) with no @relation attribute is the "one" side looking at its many children. Once you internalize that the scalar foreign key field plus the @relation annotation marks the owning side, Prisma's relation syntax stops being confusing and becomes a direct readout of the diagram's relationship lines.
One-to-one and many-to-many in Prisma
A one-to-one relationship in Prisma looks like a one-to-many except the foreign key field carries a @unique attribute, which enforces the "at most one" and is your signal to draw a one-to-one line rather than one-to-many. For example a Profile with `userId Int @unique` and a relation to User, paired with a singular `profile Profile?` on User, is one-to-one. The @unique on the foreign key is the whole difference.
Many-to-many is where Prisma offers two styles. The implicit form has a list field on both models with no explicit junction: `categories Category[]` on Post and `posts Post[]` on Category. Prisma manages a hidden join table for you, and on the ERD you draw a direct many-to-many line. The explicit form has you define the junction as its own model with two relations, which you draw as an explicit junction entity, and it is required when the relationship needs its own attributes. Recognizing which style a schema uses tells you whether to show the junction table or collapse it into a many-to-many line.
Generating and maintaining the diagram
Translating a large schema by hand is tedious, and the Prisma ecosystem has tooling to help, which you should lean on for anything beyond a handful of models.
- Community Prisma generators can produce an ERD automatically as part of running prisma generate.
- You can also convert the Prisma schema mentally or with a tool into SQL or DBML and render that as a diagram.
- In Atlas Diagram Studio, describe the schema to the AI generator at /diagram-tools/ai-diagram-generator, or import an intermediate Mermaid representation.
- After generating, arrange related models near each other; automatic layout rarely groups them well.
- Verify optionality survived the conversion: nullable fields (Type?) and unique foreign keys carry real meaning.
- Regenerate or update the ERD whenever the schema changes so the diagram stays a trustworthy reference.