Sql To Prisma Schema Converter (free & Online)

SQL to Prisma Schema Converter

The SQL to Prisma Schema Converter helps you turn SQL database definitions into Prisma Schema Language without having to rebuild every table by hand. Paste your SQL DDL, such as CREATE TABLE statements, and the tool generates Prisma-style models based on the tables, fields, keys, constraints, and relationships in your SQL.

This can be especially useful when you already have a relational database and want to start working with Prisma, or when you're reviewing an existing database structure before building it into a JavaScript or TypeScript application. Instead of manually translating each column and relationship, you can use the generated schema as a starting point and then review it against your actual database.

How Does the SQL to Prisma Schema Converter Work?

At its core, the tool takes the structure described by your SQL and expresses that same structure using Prisma Schema Language.

The basic flow looks like this:

SQL DDL → database structure → Prisma Schema Language

For example, a SQL table with an integer primary key can be represented by a Prisma Int field with the @id attribute. A text column can become a String field, while a unique constraint can become @unique. When the SQL contains a foreign key, the corresponding Prisma model can include a relation field and the necessary @relation definition.

So this isn't a mathematical conversion where one value is multiplied or divided by another. The tool is translating database concepts from one schema format into another.

SQL to Prisma Data Type Mapping

These mappings are useful as a quick reference, but they shouldn't be treated as a guarantee that every SQL dialect or database-specific type will map perfectly. Different database systems have their own native types and behaviors, so it's worth checking the generated Prisma schema whenever those details matter.

How Are Primary Keys and Auto-Increment Fields Converted?

A SQL primary key is generally represented in Prisma with the @id attribute. If the database automatically generates an integer ID, Prisma can represent that behavior with @default(autoincrement()) when it matches the original database definition.

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

One important detail is that an auto-incrementing column isn't automatically the same thing as a primary key. Those are separate database concepts, so the generated schema should reflect what the original SQL actually defines.

How Are Foreign Keys and Relationships Represented?

Foreign keys are where a simple table-to-model conversion becomes a little more interesting. A SQL foreign key can be represented in Prisma as a relationship between two models.

For example, if posts.user_id references users.id, the Prisma models can look like this:

model User {
  id    Int    @id @default(autoincrement())
  posts Post[]
}

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

The exact relationship depends on the original SQL structure. Things such as cardinality, nullability, uniqueness, and the referenced columns can affect how the relationship should be represented in Prisma.

How Are snake_case SQL Columns Mapped?

It's common for database columns to use names such as first_name while application code uses firstName. Prisma's @map() attribute lets you keep those two naming conventions separate.

model User {
  id        Int    @id @default(autoincrement())
  firstName String @map("first_name")
}

Here, your Prisma code can work with firstName, while the underlying database column remains first_name. This is useful when you want application-friendly field names without changing an existing database.

What About Composite Primary Keys?

Not every table uses a single column as its primary key. Some databases use two or more columns together to uniquely identify a row. Prisma represents this kind of composite primary key with the @@id() block attribute.

model OrderItem {
  orderId   Int
  productId Int
  quantity  Int

  @@id([orderId, productId])
}

Composite keys deserve a careful review after conversion, particularly when other tables reference them or when the schema contains compound unique constraints.

What SQL Features Should I Review?

Simple CREATE TABLE definitions are usually easier to translate, but real-world database schemas can contain much more than tables and basic columns. If your SQL uses ENUM types, JSON or JSONB fields, database-specific timestamp or numeric types, composite keys, named indexes, complex foreign keys, generated columns, triggers, views, stored procedures, or vendor-specific constraints, take a closer look at the generated result.

The converter gives you a Prisma-oriented starting point. It should not be treated as a replacement for checking the actual database structure and the behavior you need from your Prisma application.

Online Converter vs Prisma Introspection

The online converter is useful when you already have SQL DDL and want to turn it into Prisma models without connecting the tool directly to a live database. It can also be handy when you're working with migration scripts, prototyping a schema, or designing your Prisma models before connecting them to an application.

If you already have a live database and a working Prisma database connection, Prisma's own introspection command, such as npx prisma db pull, is designed to inspect that database and update your Prisma schema based on what it finds.

In other words, the two approaches start from different places: this converter starts with SQL text, while Prisma introspection starts with a connected database.

How to Use the SQL to Prisma Schema Converter

1. Prepare your SQL: Gather the CREATE TABLE statements and any relevant keys, constraints, and relationships.
2. Paste the SQL: Put your SQL DDL into the converter.
3. Generate the schema: Run the conversion to create the Prisma schema.
4. Review the result: Check the models, field types, IDs, defaults, unique constraints, indexes, mappings, and relationships.
5. Validate it: Compare the generated schema with your original SQL and make sure it matches the Prisma version and database provider used by your project.
6. Use the reviewed schema: Once you've checked the output, you can copy it into your Prisma project and continue with your normal development workflow.

Privacy and Local Execution

If the current implementation performs the conversion entirely in the browser: the SQL parsing and Prisma schema generation happen locally using JavaScript, rather than sending the SQL to an external conversion server.

Even when a tool runs locally, it's a good practice to avoid entering passwords, database connection strings, API keys, or other secrets unless you've verified how the complete website handles submitted data.

CREATE TABLE users (
  id INT PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  email VARCHAR(100) UNIQUE
);

model User {
  id    Int    @id
  name  String
  email String @unique
}

Important Validation Note

It's always worth reviewing generated Prisma code before putting it into a production project. A schema can be syntactically valid and still not represent the database exactly as intended, especially when the original SQL contains unsupported syntax, database-specific types, complex constraints, composite relationships, or other advanced features.