Prisma schema to SQL

Paste schema.prisma and take away the CREATE TABLE statements it produces — mapped table and column names, enums, foreign keys, and the join tables an implicit many-to-many creates. PostgreSQL or MySQL, no Node and no CLI, nothing uploaded.

Your schema

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

enum MembershipState {
  ACTIVE
  PAUSED
  ENDED
}

model Member {
  id          Int          @id @default(autoincrement())
  email       String       @unique @db.VarChar(160)
  fullName    String       @map("full_name") @db.VarChar(160)
  joinedOn    DateTime     @default(now()) @map("joined_on")
  memberships Membership[]
  bookings    Booking[]

  @@map("members")
}

model Plan {
  id          Int          @id @default(autoincrement())
  code        String       @unique @db.VarChar(20)
  name        String       @db.VarChar(80)
  monthly     Decimal      @db.Decimal(10, 2)
  memberships Membership[]

  @@map("plans")
}

model Membership {
  id        Int             @id @default(autoincrement())
  memberId  Int             @map("member_id")
  member    Member          @relation(fields: [memberId], references: [id])
  planId    Int             @map("plan_id")
  plan      Plan            @relation(fields: [planId], references: [id])
  state     MembershipState @default(ACTIVE)
  startedOn DateTime        @map("started_on")
  endedOn   DateTime?       @map("ended_on")

  @@index([memberId])
  @@map("memberships")
}

model Trainer {
  id           Int            @id @default(autoincrement())
  fullName     String         @map("full_name") @db.VarChar(160)
  hourlyRate   Decimal?       @map("hourly_rate") @db.Decimal(8, 2)
  specialities Speciality[]
  sessions     ClassSession[]

  @@map("trainers")
}

model Speciality {
  id       Int       @id @default(autoincrement())
  name     String    @unique @db.VarChar(60)
  trainers Trainer[]

  @@map("specialities")
}

model ClassSession {
  id        Int       @id @default(autoincrement())
  trainerId Int       @map("trainer_id")
  trainer   Trainer   @relation(fields: [trainerId], references: [id])
  title     String    @db.VarChar(120)
  startsAt  DateTime  @map("starts_at")
  capacity  Int
  bookings  Booking[]

  @@map("class_sessions")
}

model Booking {
  id        Int          @id @default(autoincrement())
  sessionId Int          @map("session_id")
  session   ClassSession @relation(fields: [sessionId], references: [id], onDelete: Cascade)
  memberId  Int          @map("member_id")
  member    Member       @relation(fields: [memberId], references: [id])
  bookedAt  DateTime     @default(now()) @map("booked_at")

  @@unique([sessionId, memberId])
  @@map("bookings")
}

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

enum MembershipState {
  ACTIVE
  PAUSED
  ENDED
}

model Member {
  id          Int          @id @default(autoincrement())
  email       String       @unique @db.VarChar(160)
  fullName    String       @map("full_name") @db.VarChar(160)
  joinedOn    DateTime     @default(now()) @map("joined_on")
  memberships Membership[]
  bookings    Booking[]

  @@map("members")
}

model Plan {
  id          Int          @id @default(autoincrement())
  code        String       @unique @db.VarChar(20)
  name        String       @db.VarChar(80)
  monthly     Decimal      @db.Decimal(10, 2)
  memberships Membership[]

  @@map("plans")
}

model Membership {
  id        Int             @id @default(autoincrement())
  memberId  Int             @map("member_id")
  member    Member          @relation(fields: [memberId], references: [id])
  planId    Int             @map("plan_id")
  plan      Plan            @relation(fields: [planId], references: [id])
  state     MembershipState @default(ACTIVE)
  startedOn DateTime        @map("started_on")
  endedOn   DateTime?       @map("ended_on")

  @@index([memberId])
  @@map("memberships")
}

model Trainer {
  id           Int            @id @default(autoincrement())
  fullName     String         @map("full_name") @db.VarChar(160)
  hourlyRate   Decimal?       @map("hourly_rate") @db.Decimal(8, 2)
  specialities Speciality[]
  sessions     ClassSession[]

  @@map("trainers")
}

model Speciality {
  id       Int       @id @default(autoincrement())
  name     String    @unique @db.VarChar(60)
  trainers Trainer[]

  @@map("specialities")
}

model ClassSession {
  id        Int       @id @default(autoincrement())
  trainerId Int       @map("trainer_id")
  trainer   Trainer   @relation(fields: [trainerId], references: [id])
  title     String    @db.VarChar(120)
  startsAt  DateTime  @map("starts_at")
  capacity  Int
  bookings  Booking[]

  @@map("class_sessions")
}

model Booking {
  id        Int          @id @default(autoincrement())
  sessionId Int          @map("session_id")
  session   ClassSession @relation(fields: [sessionId], references: [id], onDelete: Cascade)
  memberId  Int          @map("member_id")
  member    Member       @relation(fields: [memberId], references: [id])
  bookedAt  DateTime     @default(now()) @map("booked_at")

  @@unique([sessionId, memberId])
  @@map("bookings")
}

Your diagram appears here.

Replace the example with your own schema, then Export → SQL (PostgreSQL) or SQL (MySQL).

What comes out

The real PostgreSQL export of the schema above, trimmed so it fits on the page. Note the last table: nothing in the file declares it.

-- Generated with erddocs.com — paste SQL, get an ER diagram and a data dictionary
-- Target: PostgreSQL
-- Types are mapped to the target; CHECK constraints are carried only as allowed-value lists.

CREATE TYPE "MembershipState" AS ENUM ('ACTIVE', 'PAUSED', 'ENDED');

CREATE TABLE "memberships" (
  "id" serial,
  "member_id" integer NOT NULL,
  "plan_id" integer NOT NULL,
  "state" "MembershipState" NOT NULL DEFAULT 'ACTIVE',
  "started_on" timestamp NOT NULL,
  "ended_on" timestamp,
  PRIMARY KEY ("id")
);

CREATE TABLE "_SpecialityToTrainer" (
  "A" integer NOT NULL,
  "B" integer NOT NULL
);

COMMENT ON TABLE "_SpecialityToTrainer" IS 'Implicit many-to-many join table (created by Prisma)';

ALTER TABLE "_SpecialityToTrainer" ADD CONSTRAINT "_SpecialityToTrainer_A_fkey" FOREIGN KEY ("A") REFERENCES "specialities" ("id") ON DELETE CASCADE;
ALTER TABLE "_SpecialityToTrainer" ADD CONSTRAINT "_SpecialityToTrainer_B_fkey" FOREIGN KEY ("B") REFERENCES "trainers" ("id") ON DELETE CASCADE;

Read with these statements; migrate with Prisma

Worth saying before anything else. Prisma has an authoritative answer to this question:

prisma migrate diff --from-empty --to-schema-datamodel prisma/schema.prisma --script

That is Prisma’s own code, it knows your provider and preview features, and its output is what your migration will actually contain — so a database whose migration history matters should be built with it. ErdDocs covers the other case: the file on its own, with nothing installed to run against it.

What that command needs is Node, the CLI and the project checked out — which is exactly what you do not have when the schema arrived in a pull request, in a code review, in a repository you are deciding whether to take on, or on a machine where installing a toolchain to read one file is a poor trade. The statements here are equivalent in shape, not byte-identical: constraint and index names will differ from Prisma’s. They are not the place to build a migration history; what they are for is reading the schema, seeding a scratch database, and pasting the tables into a document — from the file alone, on a machine with no toolchain on it.

The table nobody wrote

specialities Speciality[] on one side and trainers Trainer[] on the other is an implicit many-to-many, and Prisma answers it by creating a table: _SpecialityToTrainer, two columns called A and B, a foreign key from each to its side. It appears in no model, in no migration you wrote by hand, and in every query you will later write against the database.

The export includes it for the same reason the diagram draws it: the database has it. The same goes for the rest of what Prisma rewrites on the way in — @@map and @map names, relation fields replaced by the scalar foreign key columns behind them, optional fields as nullable columns, and enums as a type the migration creates.

Two servers, two vocabularies

Prisma scalars are not column types, so they have to be mapped, and the target decides how:

Your @db. attributes win — @db.VarChar(160) is already a column type, so it survives exactly, precision and all.
Plain scalars are mapped — String becomes text on PostgreSQL and a sized VARCHAR on MySQL; DateTime becomes timestamp or DATETIME.
Enums differ by server — PostgreSQL gets a CREATE TYPE; MySQL, which has no such thing, gets the values inline on the column.
Identity is spelled locally — @default(autoincrement()) becomes serial on PostgreSQL and AUTO_INCREMENT on MySQL.

FAQ

Is this the same as prisma migrate diff?

ErdDocs answers the same question from the file alone — paste schema.prisma and take the CREATE TABLE statements, with no Node, no CLI and no checkout — and it is not a substitute. prisma migrate diff --from-empty --to-schema-datamodel prisma/schema.prisma --script stays authoritative: it is Prisma’s own code, it knows your provider and preview features, and its output is what your migration will contain. Use this page for the times you have the file and not the project — a review, a repository you were sent, a schema in a pull request — and for reading rather than migrating.

Can I run the result as a migration?

Run it against a scratch database, freely. Do not use it in place of prisma migrate: the statements are equivalent in shape, not byte-identical to Prisma’s, so constraint and index names will differ, and a project whose migration history matters will drift. Use it to read the schema, to seed a throwaway database, to show someone what the tables look like, or to paste into a document.

What does it do with an implicit many-to-many?

It writes the join table, because the database gets one. Two list-typed relation fields with no explicit model between them make Prisma create a table named _ModelAToModelB with A and B columns and foreign keys to both sides; the export includes it exactly as it includes the tables you declared. It is the part of a Prisma schema that most surprises people reading the database afterwards.

Which server do the types target?

PostgreSQL or MySQL, chosen in the export menu. Prisma scalars are mapped to real column types — String becomes text on PostgreSQL and VARCHAR on MySQL, DateTime becomes timestamp or DATETIME — and a @db. attribute wins where you wrote one, so @db.VarChar(160) stays varchar(160). Enums become a CREATE TYPE on PostgreSQL and inline ENUM values on MySQL, which is the only way each server has of expressing them.

Is it free?

Exporting SQL is free at any schema size, with no account and nothing installed — the 25-table free limit applies to how many tables get drawn, not to what gets converted. The file carries one comment line naming ErdDocs; a $9 license removes it, lifts the size limit and unlocks the data dictionary.

Prisma schema to ER diagram — the same schema as a picture instead of a script.
DBML to ER diagram — dbdiagram’s language, read and written.
Mermaid ER diagram generator — the same schema as README text.
Data dictionary generator — every column, type, default and index as a printable document.
Example schemas — eleven domains, each teaching one modeling pattern.
SQL to ER diagram — the tool with every format it reads and writes.