How to Generate an ERD from a Prisma Schema
Your Prisma schema already describes every entity and relationship in your database. Turning it into an ERD is less about drawing and more about translating what the schema already says.
A Prisma schema is a precise, machine-readable description of your data model - models, fields, and the relations between them. That makes it an ideal source for an entity relationship diagram, because the hard part of ERD-making, deciding what the entities and relationships are, is already done and captured in code. Generating the diagram from the schema means the picture matches reality by construction, and regenerating it after a change keeps it honest in a way a hand-drawn diagram never stays.
This guide shows how each part of a Prisma schema maps onto an ERD: models become entities, scalar fields become attributes, the @id field becomes the primary key, and relation fields plus their foreign keys become the lines with crow's foot cardinality. You can render and refine the result in Atlas Diagram Studio at /diagrams with the ERD tool at /diagram-tools/erd-tool. Because generating from code keeps the ERD in sync, this fits the broader workflow described in the guide on generating diagrams from code at /guides/how-to-generate-diagrams-from-code.
How Prisma models map to ERD entities
Each Prisma model becomes one entity box in the ERD. The model name is the entity name, and each scalar field - a String, Int, DateTime, Boolean - becomes an attribute inside the box. The field marked @id is the primary key and should be flagged as such on the diagram, and a field marked @unique is a candidate key worth noting because it enforces uniqueness just as a key would. Fields with @default or that are optional (marked with a trailing question mark on the type) carry modality information that maps to the optional or mandatory markers on relationships.
Consider this minimal Prisma schema, which the ERD reads almost line for line:
model User { id Int @id @default(autoincrement()) email String @unique name String? posts Post[] } model Post { id Int @id @default(autoincrement()) title String authorId Int author User @relation(fields: [authorId], references: [id]) }
Here User and Post are two entities. User.id and Post.id are the primary keys. Post.authorId is the foreign key, and the @relation attribute that binds authorId to User.id is exactly the relationship line the ERD draws between the two boxes.
How relations become crow's foot cardinality
Prisma relations carry all the cardinality information an ERD needs; you just have to read it. In the example above, User has a field posts of type Post[] - a list - while Post has a single author of type User. That pairing, a list on one side and a single reference on the other, is a one-to-many relationship: one user has many posts, and each post has exactly one author. On the diagram this is a single bar on the User end and a crow's foot on the Post end.
Optionality maps just as directly. If Post.author were written as author User? with authorId Int?, the post could exist without an author, which is a zero-or-one modality drawn with a circle. A one-to-one relation appears as a single reference on both sides with a @unique foreign key. A many-to-many relation - a list type on both sides with no explicit foreign key field - tells Prisma to manage a hidden junction table, and your ERD should show that junction explicitly so the physical structure is visible. Reading modifiers this way lets you translate any relation into the correct crow's foot line.
Reading a Prisma schema into an ERD, field by field
Working through a schema systematically prevents missed relationships. This checklist maps every Prisma construct to its ERD counterpart.
- Each model becomes an entity box named after the model.
- Each scalar field becomes an attribute; note its type for the physical diagram.
- The @id field is the primary key; mark it with a key indicator.
- A @unique field is a candidate key and enforces uniqueness worth showing.
- A relation field of a list type (Post[]) is the many side of a one-to-many.
- A relation field of a single type with @relation and a foreign key field is the one side.
- A list type on both models with no foreign key field is an implicit many-to-many needing a junction entity on the diagram.
- An optional type (a trailing question mark) maps to the zero-or-optional modality on the relationship end.
Keeping the ERD in sync with the schema
The whole advantage of generating an ERD from a Prisma schema is that it can never silently drift, because it comes from the same file that defines the database. The practice that captures this advantage is to regenerate the diagram whenever the schema changes, ideally as part of the same pull request that alters the model. When the diagram lives next to the code and updates with it, reviewers see the data model change visually alongside the code change, which catches design mistakes that a raw diff hides.
Once generated, bring the diagram into the editor at /diagrams to add the annotations a raw schema lacks - grouping related entities, labeling relationships in domain language, and highlighting the core tables. The generated structure guarantees accuracy; your curation makes it readable. For a text-first workflow you can also express the same model in Mermaid and refine it, as covered in the Mermaid ER diagram tutorial at /guides/mermaid-er-diagram-tutorial, and the general database design guide at /guides/database-design puts the schema in its wider context.