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
- 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).
- Paste your SQL CREATE TABLE statements. Multiple tables can be pasted at once — the converter generates a model for each table.
- Click "Generate Prisma Schema" — the output includes a datasource block, generator block, and a model for each table.
- Save the output as schema.prisma in your Prisma project, then run npx prisma generate to create the type-safe client.
- 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?
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.
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 );
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")
}