SQL to Prisma schema converter (PostgreSQL)
Convert SQL to Prisma: PostgreSQL CREATE TABLE statements, or a whole pg_dump, become a Prisma schema with relations, enums, defaults, indexes and comments, plus a baseline migration (migration.sql) that keeps what Prisma cannot describe: CHECK constraints, views, functions, triggers, identity and generated columns, partial and expression indexes.
What you get
- Your whole database: every table at once, with enums, composite keys, indexes, foreign keys and relations.
- Nothing Prisma cannot describe is lost: CHECK constraints, views, functions, triggers, identity and generated columns go into a Prisma baseline migration (migration.sql), and Prisma leaves them alone afterwards.
- Works with a whole pg_dump: session settings, ownership and data are skipped automatically.
- Checked with Prisma's own engine and the real PostgreSQL parser; default expressions are written exactly as prisma db pull writes them.
How each result is checked
- Your SQL is read by the real PostgreSQL parser, compiled to WebAssembly. When it has default expressions or generated columns, it is also run in a real PostgreSQL (PGlite) in your browser, so those expressions are written exactly as the database stores them, as prisma db pull does.
- The Prisma schema is validated and formatted by Prisma's own schema engine (Prisma 7).
- Prisma's engine reads the schema back, and every table, column type, NULL/NOT NULL, primary key, unique constraint, relation and ON DELETE/ON UPDATE rule is compared with your SQL.
- migration.sql is read back with the real PostgreSQL parser and compared with your SQL: tables, columns, types, defaults, identity and generated columns, keys, constraint names, indexes and CHECK constraints must all match.
What can't convert exactly
- Prisma's schema has no syntax for CHECK constraints, views, functions, triggers, policies or expression indexes. They go into migration.sql, exactly as you wrote them, and Prisma leaves them alone in later migrations (tested with Prisma's own migration engine: the next migration is empty).
- Indexes with INCLUDE columns can't be described in schema.prisma; migration.sql creates them, but the next prisma migrate dev offers to drop them, and the result says so.
- Types without a Prisma type (interval, point, cidr…) become Unsupported("…"); Prisma Client cannot read or write those columns.
- Tables without a primary key or unique constraint get @@ignore, as prisma db pull does.
- Session settings, ownership, GRANTs and data (INSERT, COPY) are left out of migration.sql; the result lists any that were.
Questions
How do I keep my CHECK constraints with Prisma?
Use the migration.sql this page writes as your first migration (prisma/migrations/0_init/migration.sql). It contains what prisma migrate would create from the schema, plus your CHECK constraints, views, triggers and other objects. For an existing database, mark it as applied with npx prisma migrate resolve --applied 0_init. Prisma does not remove objects it cannot describe, so later migrations keep them.
Does it match prisma db pull?
Yes: same native types (@db.…), default expressions in the exact text PostgreSQL stores (which prisma db pull reads), explicit ON DELETE/ON UPDATE, @@ignore for tables without keys, and constraint names kept with map: when they differ from the defaults. And unlike prisma db pull, nothing it cannot express is lost: it goes into migration.sql.
Prisma 6 or 7?
Prisma 7 by default, where the connection URL moved to prisma.config.ts. Choose Prisma 6 to keep url = env("DATABASE_URL") in the schema.
How is it tested?
Every test schema is executed in a real Postgres database and compared with the Prisma output column by column. The baseline migration is run on a real PostgreSQL, and Prisma's own migration engine must then find nothing to change.
How do I add a Prisma CHECK constraint?
schema.prisma has no syntax for a Prisma CHECK constraint, so it goes into a migration. Convert your SQL here: the migration.sql it writes already contains your CHECK constraints. Save it as prisma/migrations/0_init/migration.sql. For new constraints later, run prisma migrate dev --create-only and add the ALTER TABLE … ADD CONSTRAINT … CHECK line to the new migration.
Can I convert a pg_dump to Prisma?
Yes. Paste the output of pg_dump --schema-only (or a full dump): every table, enum, index and constraint is converted, and session settings, ownership, GRANTs and data are left out of migration.sql and listed in the result.
Can I convert SQL to a Prisma schema without a database connection?
Yes. prisma db pull needs a running database; here you paste CREATE TABLE statements or a pg_dump --schema-only file instead, so it works without a database connection, for example for a schema from a repository or a ticket.
Does Prisma support CHECK constraints?
The database does, but schema.prisma has no syntax for them. They live in a migration: the migration.sql written here already contains your CHECK constraints, and Prisma keeps them in later migrations.
How do I convert PostgreSQL to Prisma online?
Paste your PostgreSQL or open a file on the left (or click Example). The Prisma appears on the right as you type, already checked. Copy it, or download it as a file. Nothing is uploaded.
Can the Prisma output be wrong?
Every result is checked before it is shown (the checks are listed on this page). If a check fails, the page says "Review needed" and why, instead of presenting the output as correct, and anything that cannot convert exactly is named in the notes.