b2KIT

SQL DDL to Prisma Schema

Convert SQL CREATE TABLE statements to Prisma schema models with relations and field attributes.

Tested tool guide Tested browser tools Checked August 16, 2026

What SQL DDL to Prisma Schema does, with a checked example

Paste one or more CREATE TABLE statements and this tool returns a Prisma schema: one model per table, SQL types mapped to Prisma types, nullability turned into required or optional fields, and FOREIGN KEY clauses turned into @relation attributes with the matching back-relation on the referenced model. The conversion runs locally in the browser; the DDL you paste is not uploaded. The surprise most people hit is trust: the output is a starting point, not a verified model. Indexes, CHECK constraints, and engine-specific syntax are silently dropped or approximated, so compare the result with your real schema before relying on it.

Worked example

A concrete input and expected output from the current implementation.

Input

CREATE TABLE users (
  id INT NOT NULL AUTO_INCREMENT,
  email VARCHAR(255) NOT NULL UNIQUE,
  name VARCHAR(100),
  created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (id)
);

CREATE TABLE posts (
  id INT NOT NULL AUTO_INCREMENT,
  user_id INT NOT NULL,
  title VARCHAR(200) NOT NULL,
  published BOOLEAN NOT NULL DEFAULT FALSE,
  PRIMARY KEY (id),
  FOREIGN KEY (user_id) REFERENCES users(id)
);

Expected output

model User {
  id        Int      @id @default(autoIncrement())
  email     String   @unique
  name      String?
  createdAt DateTime @default(now())
  posts     Post[]
}

model Post {
  id        Int      @id @default(autoIncrement())
  userId    Int
  title     String
  published Boolean  @default(false)
  user      User     @relation(fields: [userId], references: [id])
}

Two tables and one foreign key is the canonical case: id maps to Int with @id @default(autoIncrement()), the nullable name gains a ?, CURRENT_TIMESTAMP becomes @default(now()), and posts.user_id becomes the userId scalar plus a user relation field, with the posts Post[] back-relation added to User.

How the result is produced

1

How the DDL is read

The tool reads CREATE TABLE statements as text and pulls out the table name, each column's name, type, and nullability, plus the constraint clauses: PRIMARY KEY, UNIQUE, NOT NULL, DEFAULT, AUTO_INCREMENT, and FOREIGN KEY ... REFERENCES. It normalizes common type synonyms (INT versus INTEGER, VARCHAR versus CHARACTER VARYING, CURRENT_TIMESTAMP), then applies Prisma's mapping rules to what it found and ignores what it does not recognize.

2

How relations and attributes are emitted

Each table becomes a model, each column a field. Type mapping: VARCHAR to String, INT to Int, TIMESTAMP to DateTime, BOOLEAN to Boolean. Nullable columns gain a trailing ?, PRIMARY KEY becomes @id, AUTO_INCREMENT becomes @default(autoIncrement()), DEFAULT CURRENT_TIMESTAMP becomes @default(now()), UNIQUE becomes @unique. A foreign key column becomes a scalar field and a relation field with @relation(fields: [...], references: [...]) and the referenced model receives a plural back-relation, such as posts Post[].

Good uses

  • Porting an existing MySQL or PostgreSQL schema into a new Prisma project, letting prisma migrate dev recreate the database instead of typing every model by hand.
  • Reading DDL you inherited: paste a coworker's or a vendor's CREATE TABLE scripts and get one model per table with the relations spelled out in Prisma syntax.
  • Prototyping a data model by sketching tables in familiar SQL, then dropping the generated models into schema.prisma as the starting point for a fresh database.

Limits and checks

  • Naming policy varies. Converters typically rename snake_case columns to camelCase fields; whether they also emit @map('column_name') to keep the original column names differs. Without @map, Prisma looks for camelCase columns at runtime, so the schema will not match an existing snake_case database. Compare against prisma db pull output or add @map attributes yourself.
  • The conversion is lossy. CHECK constraints, partial and composite indexes, generated columns, column comments, and engine-specific types are usually dropped or approximated: ENUM may come back as plain String, and CREATE INDEX statements are ignored entirely. The output validates against a fresh database but is not a faithful transcription of the source DDL.
  • Relations need disambiguation. Two foreign keys between the same pair of tables require named relations in Prisma, written @relation('name', fields: [...], references: [...]). A converter cannot invent sensible names, so multi-relation pairs may come out invalid or collapsed; check any tables that relate to each other more than once.

Common questions

Does the output work against a database I already have?

Not necessarily. Prisma derives column names from field names, so if the converter renamed columns without @map attributes, the schema will not line up with your existing tables. Generate a baseline with prisma db pull, diff it against this output, and reconcile the names by hand. If you are creating a fresh database with prisma migrate dev, the output generally works as-is.

I have a live database - should I export its DDL and convert it?

For an existing database, prefer prisma db pull: it introspects the live schema directly and sees indexes, enums, and defaults exactly as they exist, which no DDL export and conversion can match. Use this tool when the SQL exists as text - migration scripts, files, or DDL written for another project - and treat its output as a starting draft.

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