zenstack-migrate-from-prisma — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited zenstack-migrate-from-prisma (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
ZenStack V3 is designed as a drop-in upgrade path for Prisma: it keeps a Prisma-compatible query API and a schema language (ZModel) that is a superset of the Prisma schema. Most apps migrate with mechanical changes and no query rewrites. Supported databases: PostgreSQL, MySQL, SQLite.
For general setup/CLI details see zenstack-project-setup; for the client/dialect see zenstack-querying; for schema syntax see zenstack-schema-modeling.
| Prisma | ZenStack V3 |
|---|---|
prisma, @prisma/client | @zenstackhq/cli (dev), @zenstackhq/schema, @zenstackhq/orm |
schema.prisma | zenstack/schema.zmodel (Prisma schema is valid ZModel) |
prisma generate | zen generate |
prisma db push / migrate dev / migrate deploy | zen db push / zen migrate dev / zen migrate deploy |
new PrismaClient() | new ZenStackClient(schema, { dialect }) |
| bundled DB engine | you install a DB driver (pg / mysql2 / better-sqlite3) |
npm uninstall prisma @prisma/client
npm install @zenstackhq/schema @zenstackhq/orm
npm install --save-dev @zenstackhq/cliZenStack does not bundle a database engine — install the driver for your database:
| Database | Install |
|---|---|
| PostgreSQL | npm install pg + npm install -D @types/pg |
| MySQL | npm install mysql2 |
| SQLite | npm install better-sqlite3 + npm install -D @types/better-sqlite3 |
@zenstackhq/clihas a peer dependency onprisma, which is installed automatically when needed for migration commands (ZenStack's migrate commands wrap Prisma Migrate).
Move schema.prisma → zenstack/schema.zmodel. No edits are required — every valid Prisma schema is valid ZModel. Optional cleanup:
generator client { ... } block (no effect in ZenStack — code gen is driven byzen generate).
datasource block is kept; its url is used by the migration engine (the ORM runtime getsits connection from the driver/dialect instead).
importstatements.
Run `zen check` to confirm the converted schema is valid (syntax + semantics) before moving on.
Once moved, you can start adding ZenStack-only features that Prisma lacks — access policies (zenstack-access-control), @@delegate polymorphism, typed JSON, mixins, computed fields (zenstack-schema-modeling).
{ "scripts": { "generate": "zen generate" } }Run zen generate after every schema change, before using the client.
Swap new PrismaClient() for new ZenStackClient(schema, { dialect }), supplying a Kysely dialect for your driver (see zenstack-querying for all dialects). PostgreSQL example:
import { ZenStackClient } from '@zenstackhq/orm';
import { PostgresDialect } from '@zenstackhq/orm/dialects/postgres';
import { schema } from './zenstack/schema';
import { Pool } from 'pg';
export const db = new ZenStackClient(schema, {
dialect: new PostgresDialect({
pool: new Pool({ connectionString: process.env.DATABASE_URL }),
}),
});Your existing findMany/create/update/etc. calls keep working — the ORM API is Prisma-compatible.
User) — import from the generated models.UserCreateArgs) — import from the generated input.Most code relies on inferred types and needs no explicit imports.
{
"scripts": {
"db:push": "zen db push",
"migrate:dev": "zen migrate dev",
"migrate:deploy": "zen migrate deploy"
}
}Move your existing migration history from prisma/migrations to zenstack/migrations (ZenStack's default location, next to zenstack/schema.zmodel). It continues to work unchanged since ZenStack migrate wraps Prisma Migrate. See the zenstack-db-migration skill for the full migration workflow.
If you depend on Prisma custom generators (e.g. zod, ERD, type generators) that read a schema.prisma, keep emitting one with the @core/prisma plugin and chain the commands:
plugin prisma {
provider = '@core/prisma'
output = './schema.prisma'
}{ "scripts": { "generate": "zen generate && prisma generate --schema=zenstack/schema.prisma" } }| Prisma extension | ZenStack equivalent |
|---|---|
| Query extension (intercept calls) | A runtime plugin via db.$use(...) with an onQuery hook |
| Result extension (computed fields) | @computed field in ZModel + the computedFields option on ZenStackClient (see zenstack-schema-modeling) |
Verify with: zen generate → typecheck → run your test suite / app. Then incrementally adopt ZenStack's value-add features (access control, query builder escape hatch, auto CRUD APIs via zenstack-crud-server).
Already on ZenStack V2? Start here (V2 was Prisma-based), then apply the V2→V3 deltas inzenstack-project-setup(package renames, policy plugin,post-update/before(), types+mixins, grouped hooks).
Full ZenStack documentation for this topic is bundled under references/:
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.