SQL to Prisma Schema Converter

Convert SQL CREATE TABLE statements to Prisma ORM schema definitions for PostgreSQL, MySQL, SQLite, and SQL Server.

What is SQL to Prisma Schema Converter?

Prisma is a TypeScript-first ORM that uses a schema-first approach: you define your data model in schema.prisma, and Prisma generates a type-safe client from it. The schema.prisma file is the single source of truth — it defines models (which map to database tables), their fields (which map to columns), relations (foreign keys), and datasource configuration. When you inherit a database that was designed in raw SQL — or when you are migrating an existing project to Prisma — you need to convert your CREATE TABLE DDL into Prisma model syntax. This tool handles that conversion: SQL column types become Prisma scalar types (VARCHAR → String, INTEGER → Int, JSONB → Json), constraints become Prisma annotations (@id, @unique, @default), and REFERENCES become @relation directives. Prisma's schema language is more expressive than raw SQL in some ways: you can define bi-directional relations, add documentation comments, and use enum types that are enforced at the application layer. The SQL → Prisma conversion is a starting point — you will likely want to add relation names, index annotations, and potentially define enums for columns that use string constants.

How to Use

  1. Select your database dialect — PostgreSQL, MySQL, SQLite, or SQL Server. The dialect affects both the datasource provider field and the type mapping (e.g., SERIAL in PostgreSQL vs AUTO_INCREMENT in MySQL).
  2. Paste your SQL CREATE TABLE statements. Multiple tables can be pasted at once — the converter generates a model for each table.
  3. Click "Generate Prisma Schema" — the output includes a datasource block, generator block, and a model for each table.
  4. Save the output as schema.prisma in your Prisma project, then run npx prisma generate to create the type-safe client.
  5. Run npx prisma db push (for rapid prototyping) or npx prisma migrate dev (for production) to sync the schema with your database.

Why Use This Tool?

Converts SQL column types to the correct Prisma scalar type for the selected database provider — VARCHAR → String, BIGINT → BigInt, JSONB → Json, DECIMAL → Decimal
SERIAL / AUTO_INCREMENT / IDENTITY columns become @id @default(autoincrement())
REFERENCES foreign keys become @relation fields with proper fields/references syntax
Table names are preserved in @@map annotations so the Prisma model name can be PascalCase while the database table name stays as-is
Generates the complete schema.prisma boilerplate including datasource and generator blocks, ready to paste directly into a project

Tips & Best Practices

  • After converting, run npx prisma format to normalize whitespace and validate syntax — it catches relation errors before generation
  • Prisma requires explicit @relation on both sides of a foreign key relationship: the child model needs the relation field, and the parent model needs an inverse List field (e.g., posts Post[]). The converter generates the child side; add the parent side manually
  • For columns storing enum values (e.g., status VARCHAR with values "active"/"inactive"), convert the field to a Prisma enum type after generating: define enum Status { active inactive } and change status String to status Status
  • JSONB columns in PostgreSQL become the Json type in Prisma, which bypasses type safety. Consider defining a typed model or using a JSON schema validation library if the structure is known
  • Prisma does not support composite primary keys on tables that have auto-incrementing IDs — if your table uses a composite PK (PRIMARY KEY (col1, col2)), you will need to add an @@id([col1, col2]) manually and potentially restructure the model

Frequently Asked Questions

What is the complete SQL type → Prisma type mapping?

PostgreSQL: VARCHAR/TEXT → String, INTEGER/INT → Int, BIGINT → BigInt, FLOAT/DOUBLE → Float, DECIMAL/NUMERIC → Decimal, BOOLEAN → Boolean, TIMESTAMP/TIMESTAMPTZ → DateTime, DATE → DateTime, JSON/JSONB → Json, UUID → String with @db.Uuid. MySQL: VARCHAR/TEXT → String, INT → Int, BIGINT → BigInt, FLOAT/DOUBLE → Float, DECIMAL → Decimal, TINYINT(1)/BOOLEAN → Boolean, DATETIME/TIMESTAMP → DateTime, JSON → Json. SQLite: TEXT → String, INTEGER → Int, REAL → Float, BLOB → Bytes.

How does Prisma handle foreign key relations differently from SQL?

SQL defines a foreign key as a constraint on a column: user_id INTEGER REFERENCES users(id). Prisma expresses this as two parts: (1) a scalar field (userId Int) that stores the foreign key value, and (2) a relation field (user User @relation(fields: [userId], references: [id])) that Prisma uses for query joins. The parent model (User) needs an inverse field (posts Post[]). This two-sided relation declaration is unique to Prisma and is required for the client to work correctly.

When should I use Prisma vs raw SQL or Drizzle?

Use Prisma when: you want maximum type safety and auto-completion in TypeScript, you prefer a schema-first workflow, or you are building a new Node.js project with no existing schema. Use Drizzle when: you prefer writing SQL-like TypeScript queries, you want smaller bundle size, or you need more control over generated SQL. Use raw SQL (with pg, mysql2, better-sqlite3) when: performance is critical, you have complex queries that ORMs handle poorly, or you are maintaining an existing SQL-heavy codebase.

Is my SQL data sent to a server?

No. All conversion runs entirely in your browser. Your SQL schema never leaves your device.

Real-world Examples

E-commerce database: converting orders and order_items tables

A typical e-commerce database has an orders table with a foreign key to users, and an order_items table with foreign keys to both orders and products. This shows how the SQL-to-Prisma conversion handles multi-table relationships.

Input
CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  user_id INTEGER NOT NULL REFERENCES users(id),
  status VARCHAR(20) NOT NULL DEFAULT 'pending',
  total_amount DECIMAL(10,2) NOT NULL,
  shipping_address JSONB,
  created_at TIMESTAMP NOT NULL DEFAULT NOW(),
  updated_at TIMESTAMP NOT NULL DEFAULT NOW()
);

CREATE TABLE order_items (
  id SERIAL PRIMARY KEY,
  order_id INTEGER NOT NULL REFERENCES orders(id),
  product_id INTEGER NOT NULL REFERENCES products(id),
  quantity INTEGER NOT NULL,
  unit_price DECIMAL(10,2) NOT NULL
);
Output
model Order {
  id              Int        @id @default(autoincrement())
  userId          Int
  status          String     @default("pending")
  totalAmount     Decimal    @db.Decimal(10, 2)
  shippingAddress Json?
  createdAt       DateTime   @default(now())
  updatedAt       DateTime   @default(now())

  user       User        @relation(fields: [userId], references: [id])
  orderItems OrderItem[]

  @@map("orders")
}

model OrderItem {
  id        Int     @id @default(autoincrement())
  orderId   Int
  productId Int
  quantity  Int
  unitPrice Decimal @db.Decimal(10, 2)

  order   Order   @relation(fields: [orderId], references: [id])
  product Product @relation(fields: [productId], references: [id])

  @@map("order_items")
}

Related Tools