> ## Documentation Index
> Fetch the complete documentation index at: https://supaschema.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Prisma comparison
> Compare supaschema with Prisma ORM and Prisma Migrate for PostgreSQL: declarative SQL versus the Prisma schema DSL, shadow-database-free migration generation, replay and lock safety, RLS, and where each tool fits.
`supaschema` and Prisma both touch PostgreSQL schema workflows. Prisma is an ORM with Prisma Client plus Prisma Migrate, which turns the `schema.prisma` DSL into SQL migrations. `supaschema` keeps PostgreSQL SQL as the source of truth, generates guarded migrations, refreshes TypeScript and Zod outputs, runs deploy safety gates, and can apply through configured `sync` targets.
## Short answer
Use `supaschema` when you want to remove the ORM from schema ownership, migration generation, generated database contracts, and deploy safety. Keep Prisma only when you specifically want Prisma Client or the Prisma schema DSL as a product choice.
## Comparison
| Capability | supaschema | Prisma |
| ------------------------------------- | --------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| Schema source of truth | Declarative PostgreSQL SQL | `schema.prisma` DSL |
| Migration generation | Diffs PostgreSQL parse trees (libpg\_query) | Diffs the Prisma schema against migration history |
| Temporary database to generate | Not required | `prisma migrate dev` uses a shadow database |
| Replay-safety and lock-hazard linting | Yes (`supaschema check`) | Not a built-in migration linter |
| RLS, views, triggers | Modeled and diffed structurally in SQL | Prisma Migrate's native coverage is limited; Prisma's own guidance routes advanced objects through Atlas |
| Application data contract | Generated TypeScript and Zod from SQL | Prisma Client types from the schema |
| Applies migrations | Yes, through explicit or approved automatic `supaschema sync` targets | Yes (`prisma migrate deploy`) |
## Use supaschema instead of Prisma for schema, migrations, and types
`supaschema` replaces the schema-management half of Prisma — `schema.prisma` as source of truth, Prisma Migrate, and `prisma generate` for database contracts — with a SQL-owned workflow:
* **PostgreSQL SQL is the source of truth.** There is no `schema.prisma` DSL to translate, and no Postgres feature (RLS, partial and expression indexes, generated columns, exclusion constraints, extensions) has to wait for DSL support.
* **No shadow database.** Generation diffs PostgreSQL parse trees, so nothing has to be provisioned to compute a migration.
* **Migration safety is built in.** `supaschema check` gates missing guards, table rewrites, and non-transactional index creation as `SUPA_*` diagnostics — a step Prisma Migrate does not have.
* **Typed data access without the ORM schema layer.** `supaschema types` generates TypeScript types and Zod validators from the SQL. Application code can use those contracts with a PostgreSQL driver, a platform client, or an optional query builder.
How the workflow maps onto what Prisma does:
1. Write the schema as declarative SQL in `schemaPaths` (replaces editing `schema.prisma`).
2. `supaschema diff` renders a replay-safe migration (replaces `prisma migrate dev`), with no shadow database.
3. `supaschema check` proves replay safety and lock impact (no Prisma equivalent).
4. `supaschema types` regenerates the TypeScript and Zod outputs (replaces the database-contract part of `prisma generate`).
5. Apply the SQL with `supaschema sync` or another Postgres migration runner (replaces `prisma migrate deploy`).
6. Execute PostgreSQL SQL through your runtime driver or platform client, using generated TypeScript and Zod helpers as the application boundary.
## What stays optional
* Prisma Client can still be useful when your team wants Prisma's query API, relation mapping, and client conventions. It is not required for schema ownership, generated types, validators, migration generation, or deploy safety.
* Prisma Migrate remains a Prisma workflow for teams that intentionally want `schema.prisma` and Prisma migration history to own the database.
* If your team prefers modeling schema in the Prisma DSL and generating both schema and client from one file, Prisma's model fits that preference. If PostgreSQL SQL should be the contract, use supaschema as the owner.
See [ORM-free applications](/docs/concepts/orm-free-applications) for the canonical directive.
Last verified 2026-06-17 against the Prisma documentation. Prisma evolves;
confirm current behavior before relying on it.
How supaschema compares to Drizzle's TypeScript-schema migration workflow.
The replay-safety and lock-hazard diagnostics supaschema runs on each
migration.
Use generated TypeScript and Zod contracts without an ORM schema layer.
## Sources
* [Prisma Migrate overview](https://www.prisma.io/docs/orm/prisma-migrate)
* [A mental model for Prisma Migrate](https://www.prisma.io/docs/orm/prisma-migrate/understanding-prisma-migrate/mental-model)
* [About the shadow database](https://www.prisma.io/docs/orm/prisma-migrate/understanding-prisma-migrate/shadow-database)
* [Advanced schema management with Atlas and Prisma ORM](https://www.prisma.io/blog/advanced-database-schema-management-with-atlas-and-prisma-orm)