b2KIT

Prisma Schema Editor

Edit Prisma schema files with syntax highlighting, model validation, and relation visualization.

Tested tool guide Tested browser tools Checked August 16, 2026

What Prisma Schema Editor does, with a checked example

Prisma schemas are hand-written text, and the errors that hurt live in the relations between models, not in the syntax. This tool parses the Prisma Schema Language (PSL), highlights syntax as you type, and validates models the way prisma validate does, flagging broken relations, missing ids, and mismatched field types before you ever run a migration. It also draws the data model as a diagram of model boxes and relation edges. The surprise for most users: every relation must be declared on both models. Listing the foreign key on one model and nothing on the other is a validation error, not an omission the tool will fill in.

Worked example

A concrete input and expected output from the current implementation.

Input

datasource db {
  provider = "postgresql"
  url      = "postgresql://user:pass@localhost:5432/mydb"
}

model User {
  id Int @id @default(autoincrement())
}

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

Expected output

Validation reports an error: "The relation field `author` on model `Post` is missing an opposite relation field on the model `User`." Both models render in the diagram, but the relation edge between them is flagged as invalid rather than drawn as a resolved connection.

Prisma requires every relation to be declared on both participating models: one side carries the foreign key (`author` with `fields: [authorId]`), and the other must declare the matching list field (`posts Post[]`). With only one side declared, the relation cannot be resolved, so validation rejects the schema.

How the result is produced

1

Parsing and validation

The schema text is parsed into models, fields, and attributes. Validation then walks every `@relation`: it pairs `fields` with `references` element by element, checks that the two arrays have equal length and matching types, verifies an opposite relation field exists on the target model, and confirms every model carries an `@id` or `@@id`. Each error is reported against the specific model or field, mirroring what the `prisma validate` command reports.

2

Relation diagram

Each model becomes a box in the diagram listing its fields; relation fields become edges to other boxes. Cardinality is inferred from the schema: a foreign key without `@unique` is one-to-many, with `@unique` it is one-to-one, and two list fields with no `@relation` attribute form an implicit many-to-many edge whose generated join table the tool renders as part of the relation.

Good uses

  • You are about to run `prisma migrate dev` and want to catch broken relations first: paste the schema, fix what validation flags, then migrate with confidence that the data model parses.
  • You inherited an unfamiliar schema: load it into the editor and read the diagram to see which models connect to which, at what cardinality, and what a cascading delete would touch.
  • You are learning Prisma relations: sketch one-to-one, one-to-many, and many-to-many shapes by hand and watch the diagram update, rather than guessing which `@relation` arguments each shape needs.

Limits and checks

  • Validation checks the schema text, not the database. A schema can validate cleanly while the real database has drifted from it (renamed columns, missing tables). Comparing against a live database requires the Prisma CLI: `prisma migrate diff` or `prisma db pull`.
  • Native types are provider-specific. `@db.TinyInt` validates for a `mysql` datasource but is rejected when the provider is `postgresql`. The editor can only judge native types if your `datasource` block is present with its provider set, so pasting a bare model fragment may validate differently from the full file.
  • Implicit many-to-many relations hide a real table. `User.roles Role[]` plus `Role.users User[]` draws a direct edge in the diagram, but Prisma generates an actual `_RoleToUser` table. If you need to rename it or add columns, you must convert the relation to an explicit one with `@relation`.

Common questions

Why does validation say my relation needs a name even though both sides exist?

When two models have more than one relation between them, Prisma cannot tell which fields pair with which. Add the same `name` argument to both sides, for example `@relation(name: "AuthorPosts", fields: [authorId], references: [id])`. If the names differ or only one side carries one, validation fails.

Does the editor connect to my database or run migrations?

No. It parses and validates the schema you paste and renders the diagram from that text alone; nothing connects to a database and no migrations are generated. Anything that touches the real database - `prisma migrate dev`, `prisma db pull`, `prisma generate` - runs through the Prisma CLI, not this tool.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools