VendorPulse
Prisma

Prisma

✓ VerifiedGitHub

Next-generation Node.js and TypeScript ORM for PostgreSQL, MySQL, SQLite, and more.

Website →Last scanned 5 hours ago

Releases

19
v8.0.0-rc.4

v8.0.0-rc.4

1 day ago

v8.0.0-rc.4

The transition period for the old ORM config is over, and two fixes land for the consolidated prisma CLI stack. Most projects created before rc.2 need the config migration below; projects scaffolded by rc.2+ init need nothing.

The upgrade recipe for this hop: the user recipe.

Breaking changes

  • The deprecated config fallbacks are gone — the CLI no longer reads prisma-next.config.ts and no longer accepts the flat (un-nested) config shape; both now fail loudly instead of warning. The only config read is prisma.config.ts in the envelope shape, and the workspace prisma-next binary is retired — the unified CLI runs the ORM commands at the top level. Rename the file, wrap your ORM options in definePrismaConfig({ orm: ormConfig({ … }) }), and keep import 'dotenv/config' if your config reads process.env. See the user recipe for the exact rewrite. (#30058)

    Before:

    // prisma-next.config.ts
    import { defineConfig } from '@prisma/orm-postgres/config';
    
    export default defineConfig({ contract: './contract.prisma', db: { connection: process.env['DATABASE_URL']! } });
    

    After:

    // prisma.config.ts
    import 'dotenv/config';
    import { definePrismaConfig } from '@prisma/cli-engine';
    import { defineConfig as ormConfig } from '@prisma/orm-postgres/config';
    
    export default definePrismaConfig({
      orm: ormConfig({ contract: './contract.prisma', db: { connection: process.env['DATABASE_URL']! } }),
    });
    

Fixes

  • contract emit no longer crashes after writing its artifacts when the project root is a relative path — validateContractDeps() resolves the root before handing it to Node's createRequire(), which requires an absolute path. (#30064)
  • init scaffolds definePrismaConfig, the current name for the config marker in @prisma/cli-engine 0.2.0, instead of the deprecated defineConfig alias. (#30064)
v8.0.0-rc.3

v8.0.0-rc.3

2 days ago

v8.0.0-rc.3

A single-purpose release: @prisma/orm-toolchain moves its exact @prisma/cli-engine peer from 0.1.1 to 0.2.0, so the unified prisma CLI can ship a release in which every mounted product runs on the one engine version it installs. There are no ORM API changes in this release.

Breaking changes

  • The exact @prisma/cli-engine peer moves to 0.2.0 — engine 0.2.0 adds the credential-refresh exports and structured delegated output that prisma@8.0.0-rc.4 was built against but the registry's engine 0.1.1 does not contain, which is why npx prisma@next currently fails on import. This release pairs with the prisma CLI release that depends on it (8.0.0-rc.5); upgrade both together. No code changes — an operational peer move only. (#30056)
v8.0.0-rc.2

v8.0.0-rc.2

2 days ago

v8.0.0-rc.2

This release retires the prisma-next binary in favour of the unified prisma CLI, returns the default aggregates to plain JavaScript numbers with lossless variants beside them, makes CHECK constraints a declared part of the contract, and splits runtime row queries from non-returning writes. Almost every application will need to re-emit its contract and rename its config file, so read the breaking changes before upgrading.

Two upgrade recipes carry the mechanical translations for this hop: the user recipe and the extension-author recipe.

Breaking changes

  • This repository no longer publishes a CLI; the unified prisma CLI replaces it — nothing published ships a prisma-next bin anymore. @prisma/orm-toolchain exposes the orm command family at @prisma/orm-toolchain/cli and no binary, and the database facades forward no launcher. Install @prisma/cli (the prisma-cli distribution, published under next for the v8 line) and replace prisma-next <command> in package scripts and CI with the unified CLI. The config file moves with it: prisma-next.config.ts is deprecated in favour of prisma.config.ts, and the config value is now engine-shaped, with your existing ORM config nested under an orm section. Both the old filename and the flat shape still load, each printing a deprecation warning on stderr, so the rename and the rewrap can land separately. See the user recipe. (#30005)

    Before:

    // prisma-next.config.ts
    import { defineConfig } from '@prisma/orm-postgres/config';
    
    export default defineConfig({ contract: './contract.ts', output: './generated' });
    

    After:

    // prisma.config.ts
    import { defineConfig } from '@prisma/cli-engine';
    import { defineConfig as ormConfig } from '@prisma/orm-postgres/config';
    
    export default defineConfig({
      orm: ormConfig({ contract: './contract.ts', output: './generated' }),
    });
    
  • The default aggregates are JavaScript numbers again, with lossless variants beside themcount(), sum() over an integer column, and avg() over an integer column all return number. In 8.0.0-rc.1 they returned a bigint, a bigint or decimal string depending on the column's width, and a decimal string respectively. The lossless results moved to three new operations: countBigInt() returns a bigint, sumBigInt() returns a bigint, and avgDecimal() returns an exact decimal string (PostgreSQL only — SQLite has no decimal type and contributes none). A count() or integer sum() whose value passes ±(2^53 − 1) now raises RUNTIME.DECODE_FAILED rather than returning a rounded number, so move those calls to the BigInt variants where the magnitude is real. Unchanged: min/max, sum/avg over a float column, sum over Decimal, sum over UnboundedInt, and the ORM's having(...) operands. The SQL builder's comparison operands do move, because fns.gt(a, b) types both sides from one codec. The same PR also makes the wide-integer codecs refuse the wrong JavaScript type: a BigInt or UnboundedInt column rejects a number and a BigIntNumber column rejects a bigint, with RUNTIME.ENCODE_FAILED naming the type that arrived, where previously a number was accepted and stringified — which let a fractional value reach an integer column unremarked. See the user recipe. (#29930)

    Before:

    const { total } = await db.User.aggregate((a) => ({ total: a.count() }));
    total === 2n; // bigint
    
    const busy = await db.sql.public.user
      .groupBy('kind')
      .having((_f, fns) => fns.gt(fns.count(), 1n)); // bigint literal
    

    After:

    const { total } = await db.User.aggregate((a) => ({ total: a.count() }));
    total === 2; // number — countBigInt() returns the bigint
    
    const busy = await db.sql.public.user
      .groupBy('kind')
      .having((_f, fns) => fns.gt(fns.count(), 1)); // plain number literal
    
  • Which aggregate methods exist is now the contract's answer — the aggregate methods are no longer declared on the ORM and SQL-builder surfaces outright. Each surface is derived from the operation names in the emitted contract.d.ts's AggregateTypes block, so a target or extension can contribute an operation and it appears under its own name with no client change. PostgreSQL now contributes eight operations and SQLite seven. Re-emit your contract with the CLI's contract emit: against a contract with no AggregateTypes block — one authored in code with defineContract(...) and handed straight to the client, or emitted before 8.0.0-rc.1 — every aggregate surface resolves to AggregateOperationsUnavailable, an empty type, and each call becomes a compile error. What this release changes is compile-time only — the separate runtime guard introduced in 8.0.0-rc.1 still stands, rejecting an aggregate whose operation and input codec the composed target does not declare with ORM.AGGREGATE_UNSUPPORTED before the query runs. Separately, count(field) now renders COUNT(<column>) instead of accepting the argument and discarding it, so a call that got past the types — a @ts-expect-error, a count(x as never), or dynamic dispatch — now counts that field's non-null values rather than rows. See the user recipe and the extension-author recipe. (#29922)

  • CHECK constraints are declared in the contract, and introspection now sees all of them — the CHECK shape in contract.json changed from { name, column, valueSet } to { name, prefix, expression }, where expression is the raw SQL predicate and name is a content-addressed wire name (<prefix>_<8hex>, the convention indexes and RLS policies already use). An old-shape contract is rejected on read, so re-emitting is not optional. Three consequences to plan for. Your first migration plan after upgrading drops each old unsuffixed enum constraint and adds the wire-named one, which needs destructive to converge. Every list (many) column gains a declared element-non-null CHECK the planner previously created without declaring. And introspection stopped parsing predicates, so hand-written constraints earlier versions could not see are now visible — and an undeclared check is an extra that db verify --strict reports and a destructive-capable plan drops, so read the first plan for dropCheckConstraint operations naming constraints you wrote yourself, and declare each one you want to keep with @@check(expression: "…", map: "<physical name>"). Two API changes ride along: addCheckConstraint in committed migration files takes an expression instead of a column/values pair, and the typescriptContract options bag now requires createNamespace whenever it passes defaultControlPolicy. An enumType() whose codec is numeric now throws CONTRACT.ENUM_INVALID while the contract is being built rather than failing later at migrate time. See the user recipe and the extension-author recipe. (#29892)

    Before:

    this.addCheckConstraint({ schema, table, constraint, column: 'kind', values: ['admin', 'user'] });
    

    After:

    this.addCheckConstraint({ schema, table, constraint, expression: `"kind" IN ('admin', 'user')` });
    
  • Runtime row queries and non-returning writes are separate callsquery() streams rows and execute() resolves { affectedRows }, which is how a write now reports its affected count without a preceding SELECT. Classify each call site by the result it consumes rather than replacing every execute: a select, a returning write, or any plan whose rows are iterated, indexed, or decoded moves to query, while an insert, update, or delete that returns nothing stays on execute and reads affectedRows. Prepared row consumption moves from target.queryPrepared(prepared, params) to prepared.query(target, params). Runtime middleware splits the same way, into beforeQuery / interceptQuery / afterQuery and beforeExecute / interceptExecute / afterExecute with a shared beforeCompile; query interception returns { rows } and execute interception returns { stats }. There is no operation discriminator, compatibility alias, or generic fallback hook. On Mongo, db.query stays the static builder and the row-executing db.execute facade method is gone — build with db.query, then execute through (await db.runtime()).query(plan). See the user recipe. (#29921)

  • raw is a reserved storage namespace — the SQL surface exposes the whole-query raw statement tag as db.sql.raw, so a storage namespace of that name would be unreachable through the builder while the emitted types still promised its tables. Building the client now raises ORM.NAMESPACE_RESERVED naming the namespace. Rename it in your schema, re-emit the contract, and plan the rename against the database as you would any other namespace rename. Only raw is reserved. (#29997)

    Before:

    model Event {
      id String @id
      @@schema("raw")
    }
    

    After:

    model Event {
      id String @id
      @@schema("ingest")
    }
    
  • Codec ids are checked where you write them — a codec id in a prepared declaration or in a contract-bound raw fragment is now checked against your contract's codec map, so an id the contract does not carry is a compile error instead of an execution-time RUNTIME.PARAM_REF_MISSING_CODEC. The usual cause is an unversioned id. Read the correct spelling off your emitted contract.d.ts — every id it carries now completes at both positions. A raw fragment built through a contract-free lane is unaffected, since it has no map to check against. (#30011)

    Before:

    await db.prepare({ id: 'pg/int4' }, (sql, params) => /* … */);
    const upper = fns.raw`UPPER(${f.email})`.returns('pg/text');
    

    After:

    await db.prepare({ id: 'pg/int4@1' }, (sql, params) => /* … */);
    const upper = fns.raw`UPPER(${f.email})`.returns('pg/text@1');
    
  • db update takes consent by database name, and --yes no longer grants it — a plan that would destroy data is refused until you type the name of the connected database, and the consent binds to that exact plan by hash. --yes never grants it; the CLI style guide has always said a blanket confirmation flag must not stand in for a destructive confirmation. Non-interactive runs grant with --confirm <database>. A dry run, or a plan with nothing destructive in it, never asks. Update any CI invocation that relied on -y to apply a destructive plan. (#29986)

  • The diagnostic commands exit 4 on findings and 2 on errorsdb verify, db sign, and migration check now distinguish "I ran and found problems" (exit 4) from "I could not run" (exit 2). Exit 1 is reserved for a bug in the CLI itself, and exit 0 still means the check ran and found nothing. db verify and db sign previously exited 1 on findings, and migration check exited 2. Scripts that test for any non-zero exit are unaffected; scripts that match a specific code must be updated. (#29984)

  • Four migration status flags are retired--graph, --all, --limit, and --ref moved to their own commands. An old invocation now gets a typed CLI.COMMAND_MOVED error naming the replacement rather than failing as an unknown flag. (#29982)

  • Prepared statements split by their declared resultruntime.prepare() returns one of two handles chosen from the plan the callback builds: a rows plan gives the PreparedStatement you already have, consumed with .query(target, params), while a plan whose declared result is an affected-row count gives a PreparedExecution, consumed with .execute(target, params). This matters to extension authors: a facade that redeclares prepare() changes its return type to PreparedFor with no logic change, and a scope that installs the prepared-query bridge must also install the execute bridge or prepared.execute throws on the bridge invariant. See the extension-author recipe. (#30006)

Features

  • Whole-query raw SQL replaces the classic $queryRaw / $executeRaw use case. A whole statement is authored with the same tagged template the fragment mechanism already used, terminated with .returnsRow(rowSpec) for decoded, typed rows or .affectedCount() for a mutation count, and built into an ordinary query plan that flows through the existing lowering, codec, guardrail, and execution machinery — no new query lane and no new execution surface. Row-returning raw queries interpolate into other raw templates as subqueries, which gives CTEs, including data-modifying ones, for free. (#29997)
  • @@check(expression: "…") declares a CHECK constraint in the schema, and contract infer adopts the ones your database already has. Use name: for a wire-name prefix, so the physical constraint is name_<8hex> hashed over the predicate and compared by name — which means Postgres reprinting the expression never causes drift. Use map: to adopt a constraint under its existing physical name, comparing the predicate byte-for-byte. Pulling a database now emits @@check for every live check Prisma Next did not derive, so a hand-written constraint is declared from the first pull instead of reading as an undeclared extra. (#29972)
  • @noCheck opts a column out of the CHECK constraints Prisma Next derives for it, per kind: @noCheck suppresses all of them, @noCheck(membership) keeps the element-non-null check on a list column while dropping the membership check, and @noCheck(elementNotNull) does the reverse. The TypeScript builder equivalent is .noCheck(...). contract infer emits the attribute too, so a pulled schema passes db verify --schema-only immediately instead of needing one migration first. (#29928)
  • Two new column types make integer representation a per-column choice without changing the lossless BigInt default. BigIntNumber reads and writes as a JavaScript number, throwing outside ±(2^53 − 1) instead of rounding. UnboundedInt uses PostgreSQL unconstrained numeric storage and round-trips integral values as exact bigint values at arbitrary magnitude. PostgreSQL contributes both; SQLite contributes BigIntNumber. (#29902)
  • The minimum supported PostgreSQL version drops from 17 to 15, the oldest version CI has been exercising all along. init scaffolds and the --probe-db warning threshold follow the new floor. The reasoning is recorded in ADR 244. (#29971)
  • Renaming a model or column whose CHECK constraint content is unchanged now plans a single ALTER TABLE … RENAME CONSTRAINT, classed widening, instead of a drop plus an add. A cosmetic rename no longer needs a destructive-capable plan or a full table revalidation. (#29894)
  • Errors carry typed next actions. A failure that has a remedy now ships it as structured data — nextActions, each naming a command to run — raised at the site that holds the arguments rather than spelled out in English prose a caller would have to parse. The binary name is templated at the raise site and substituted when rendered, so the suggestion stays correct as the CLI is renamed. (#29977)
  • CLI failures report their real error code. envelope.code is the stable surface consumers branch on, and a dozen failures previously reported CONTRACT.VERIFY_FAILED while hiding the true code in metadata. Every construction site now declares its code explicitly, fourteen new codes were added for the failures that had none, and the generic error path gained cause support. (#29919)
  • Config loading reports diagnostics per section instead of throwing on the first problem it finds. A command fails only when a section it actually reads is broken, so a malformed formatter section no longer blocks db init. Each diagnostic is tagged with the config section and field it concerns. (#29936)

Fixes

  • init no longer fails at its contract-emit step against the published packages. The step now runs the scaffolded project's own CLI binary as a subprocess rather than loading the new config in-process with the running CLI's bundled loader, and its failure message carries the child's stderr so a real cause is visible. The schema-path prompt also shows its default as placeholder text instead of looking blank until a keypress. (#30018)
  • contract emit picks the import specifier for the emitted contract.d.ts by reading the nearest package.json above the file it is writing, rather than falling back to the process working directory. Running the command from the wrong directory previously wrote an unresolvable internal specifier into the generated file. (#29981)
  • Synthesized foreign-key-backing index name prefixes are truncated to fit PostgreSQL's 63-byte identifier limit, so a mapped explicit join table no longer fails contract emit before the content hash can be appended. User-authored over-budget index prefixes still fail loudly. (#30025)
  • A raw row spec column named __proto__ is now refused loudly instead of silently vanishing — bracket assignment onto an object literal hit the inherited setter, so the key never became an own property and the record was quietly re-parented. constructor and prototype create ordinary own properties and round-trip faithfully. (#30014)
  • The PostgreSQL direct driver no longer ends a caller's transaction. A driver-level read issued while its connection held an open transaction reported no transaction in progress, took the cursor portal-protection path, and wrapped itself in BEGIN/COMMIT — and that COMMIT ended the caller's transaction, so later statements ran autocommit and ROLLBACK undid nothing. The driver and its connection now share the transaction-open flag. (#29920)
  • ORM mutation reloads encode Bytes identities through the column codec, so a repeated upsert keyed on a Bytes column no longer raises ORM.MUTATION_ROW_MISSING. Every unbound literal entering a select through raw collection state now becomes a typed parameter. (#29910)

New contributors

v8.0.0-rc.1

v8.0.0-rc.1

1 week ago

v8.0.0-rc.1

This is the first release on the v8 release-candidate line: releases are now versioned 8.0.0-rc.N instead of 0.x minors. It also makes every aggregate read back through the codec its target declares — count() returns a bigint — splits the SQL driver interface into a row-streaming call and a statistics call, and fixes four defects in query planning, emit, and driver error reporting.

The v8 release-candidate line

Releases are now versioned 8.0.0-rc.1, 8.0.0-rc.2, and so on, with the counter advancing on every release. "The v8 RC" is the product name; the number underneath iterates freely, so there is no promise that the last RC before 8.0.0 final is numbered rc.1. There are no further 0.x minors. The policy is written up in docs/oss/versioning.md. (#29899)

For every package this repository publishes, latest keeps tracking the newest release, RC included. These package names have no pre-v8 stable audience to protect — a bare npm install of one of them was already an early-access install, and still is. The bare prisma package is not published from this repository; its v8 CLI shim lives in prisma/prisma-cli.

Existing installs are not moved onto the RC line by npm update. Lockfiles pin resolved versions, and a ^0.x range can never match a 8.0.0-rc.N pre-release, because pre-releases do not satisfy stable ranges. Only a fresh install, or an explicit version change on your side, lands on the RC.

Development builds move to the same line: every push to main that does not change the root version publishes 8.0.0-rc.X-dev.N under the dev dist-tag.

An RC respin may still contain breaking changes. Until 8.0.0 final ships, the pre-1.0 latitude documented in docs/oss/versioning.md carries over: a new rc.N may remove or rename APIs, change the semantics of existing ones, or change the contract format. Read the breaking-changes section of each release before you upgrade.

Breaking changes

  • Aggregate results carry the codec their target declares — an aggregate is now read back through the codec its target declares for that result rather than through whatever the driver handed over, so aggregate application types change. count() is a bigint on both PostgreSQL and SQLite, at the top level and inside an include, and an empty relation reads 0n. On PostgreSQL, sum over int2/int4 widens to a bigint, while sum(int8) and avg over any integer are numeric and read as exact decimal strings; min/max keep the column's own type, except over varchar, which returns text. On SQLite, sum over an integer column is a bigint and avg is always a number. Sweep your code for equality and arithmetic against an aggregate result (count === 2 is false when count is 2n) and for JSON.stringify over one (it throws on a bigint). having(...) operands are the exception and stay plain numbers — they are compared inside SQL and never cross a codec. Regenerate your contracts (prisma-next contract emit): contract.d.ts gains an AggregateTypes block that both the ORM and the SQL builder resolve result types from, and against an older contract an aggregate resolves to never in the ORM and unknown in the SQL builder. The type is not the only guard: an aggregate whose operation and input codec the composed target does not declare is rejected before the query runs, with the error code ORM.AGGREGATE_UNSUPPORTED. See the upgrade recipe and the extension-author recipe. (#29867)

    Before:

    const rows = await posts.include('comments', (comments) => comments.count()).all();
    rows[0].comments === 2; // number; 0 when the relation is empty
    

    After:

    const rows = await posts.include('comments', (comments) => comments.count()).all();
    rows[0].comments === 2n; // bigint; 0n when the relation is empty
    
  • The SQL driver interface splits row streaming from statement statisticsSqlQueryable (exported from @internal/sql-relational-core/ast) is now two methods wide: query() streams rows and execute() returns { affectedRows }. The separate prepared-execution method is gone; a prepared plan is expressed by an optional preparedStatementHandle on the request instead, and a driver branches on whether that property is undefined. Application code, query results, and the contract format are unaffected — this only matters if you implement or wrap SqlQueryable yourself, in which case update your implementation to the two-method shape. There is no upgrade recipe entry for this; the change is the interface itself. (#29907)

    Before:

    interface SqlQueryable {
      execute<Row>(request: SqlExecuteRequest): AsyncIterable<Row>;
      executePrepared<Row>(request: PreparedExecuteRequest): AsyncIterable<Row>;
      query<Row>(sql: string, params?: readonly unknown[]): Promise<SqlQueryResult<Row>>;
    }
    

    After:

    interface SqlQueryable {
      query<Row>(request: SqlExecuteRequest): AsyncIterable<Row>;
      execute(request: SqlExecuteRequest): Promise<SqlStatementStats>;
    }
    

Features

  • prisma-next init installs one prisma-8 skill instead of eleven per-workflow skills, and removes the retired skill directories from every agent's install root on each run. Each skill is now installed by name — prisma-8, prisma-next-upgrade, and prisma-8-extension-upgrade — rather than by matching a wildcard against a directory, so a new skill landing beside them is not picked up by accident. (#29853)

Fixes

  • A column, table, or model mapped to a name that is not a bare TypeScript identifier — @map("has space"), @@map("data rows") — now emits a quoted property key in contract.d.ts instead of producing a syntactically invalid file that killed contract emit. String literals in emitted TypeScript also survive control characters and line separators, which previously produced the same failure by a different route. (#29889, #29898)
  • Nested some/every/none predicates over a self-referential relation now keep a distinct SQL alias at every level, so an inner scope no longer shadows the parent it is supposed to correlate against. This covers one-to-one, many-to-one, one-to-many, implicit many-to-many, and explicit-junction many-to-many relations in both directions, and relations whose physical tables share a bare name across namespaces. (#29900)
  • Scalar reducers on a many-to-many include — count(), sum(), avg(), min(), max() — now traverse the junction table instead of emitting a predicate against a foreign-key column that only exists on the junction, so a filtered relation count over a many-to-many relation returns the right number. (#29888)
  • A failed retry of a stale PostgreSQL prepared statement now surfaces a structured error envelope with the code DRIVER.PREPARE_FAILED, carrying the normalized driver error as its cause, instead of an unlabelled failure. (#29907)
v0.17.0

v0.17.0

2 weeks ago

v0.17.0

This is the namespace release: Prisma Next now publishes as 17 packages under the @prisma scope, and an application depends on exactly one database facade. It also completes the structured error-code scheme across every plane, makes relation-loading lossless for big numbers and temporal values, and gives every SQL index and RLS policy an exact, migratable name.

Breaking changes

  • One @prisma package per application — the @prisma-next/* scope is retired; nothing publishes under it again. An application depends on exactly one database facade — @prisma/orm-postgres, @prisma/orm-sqlite, or @prisma/orm-mongo — plus any extension packs it uses (now named @prisma/orm-extension-*); everything else arrives as the facade's exact-pinned dependencies. Regenerating your contract rewrites generated imports to facade entrypoints with no contractHash change. See the 0.16-to-0.17 upgrade recipe and the extension-author recipe. (#29864, #29880, #29883, #29884)

    Before:

    "dependencies": {
      "@prisma-next/postgres": "0.16.0",
      "@prisma-next/framework-components": "0.16.0",
      "@prisma-next/sql-runtime": "0.16.0"
    }
    

    After:

    "dependencies": {
      "@prisma/orm-postgres": "0.17.0"
    }
    
  • Every published error is a structured envelope with a dotted code — the four legacy error systems (PN-CLI-4001-style codes, RUNTIME.DECODE_FAILED-style codes, and codeless error classes) consolidate into one scheme: a structural envelope carrying a NAMESPACE.SUBCODE code, recognized by the isStructuredError type predicate instead of instanceof. The ORM, contract-authoring, adapter/target, extension, and framework planes are all swept; legacy error classes (PslFormatError, the Supabase and SQL-escape classes, framework classes) are deleted. Prisma 7's P1001-style codes are not carried over. (#1016, #1021, #1025, #1049, #1053, #1063)

    Before:

    if (error instanceof PslFormatError) {
      report(error.diagnostics);
    }
    

    After:

    if (isStructuredError(error) && error.code === 'PSL.PARSE_FAILED') {
      report(error.meta.diagnostics);
    }
    
  • Content hashes are bare hex — the sha256: prefix is gone from every surface (emitted contracts, migration manifests, refs, CLI output, and the database marker), and loaders reject the prefixed form. Contract hash values are unchanged; migrationHash values change. A codemod in the 0.16-to-0.17 recipe converts checked-in migration trees. (#1033)

  • Migration contract snapshots move into a content-addressed store — per-migration sibling snapshot files and ref-paired copies are replaced by a single migrations/snapshots/<hex>/ store per migrations root; every distinct contract is stored once, and migration.ts imports its bookend contracts from the store. This is a clean break with no fallback reader; a one-shot migrator (scripts/migrate-migrations-layout.mjs) converts existing trees and re-verifies every migrationHash unchanged. (#1018, #1024)

  • PostgreSQL native types are authored in type position; the @db.* attribute channel is removed — write the native type directly (VarChar(255), Uuid, Timestamptz) instead of a base type plus @db.* attribute; remaining @db.X(args) usage fails with the exact replacement spelled out. Json re-binds to native json storage, with a new Jsonb scalar for jsonb (what every pre-0.16 Json field meant — switch those fields to keep a byte-identical contract), and Date re-binds to the correct pg/date@1 codec. (#1022, #1036, #1054)

    Before:

    model User {
      id    String @id @db.Uuid
      name  String @db.VarChar(255)
    }
    

    After:

    model User {
      id    Uuid         @id
      name  VarChar(255)
    }
    
  • Relation-loading and aggregates are lossless — values read through .include() no longer pass through lossy JSON: every codec gains an explicit lossless JSON form produced inside the database. 64-bit integers arrive as bigint instead of silently rounding, decimals as exact strings, and temporal columns decode correctly. Aggregate result types change accordingly: count() is a bigint, decimal sums are strings. Regenerate your contract after upgrading. (#29844, #1023, #1051)

  • SQL indexes and RLS policies are name-identified — every index and RLS policy carries an exact name in the contract, names travel on the wire, live objects can be adopted by exact name (@@map), and a rename converges by renaming instead of drop-and-recreate. (#1047, #29807, #29865)

  • extensionPacks config key renamed to extensions — in prisma-next.config.ts, the TS builder, client options, and the emitted contract's top-level key. The old key fails loudly. Because the key sits in the hashed contract bytes, all contract hashes change: re-emit and re-anchor migrations per the recipe. Two smaller key renames ride along: contract.source.sourceFormatformat, and the facade defineConfig option outputPathoutput. (#1032)

  • Count-only mutation terminals renamedcreateCount(...) / updateCount(...) / deleteCount() become createAndCount(...) / updateAndCount(...) / deleteAndCount(); behavior and Promise<number> results are unchanged, with no compatibility aliases. (#1044)

Features

  • Expression, partial, and unique indexes are authorable in both PSL and the TypeScript builder. (#1048)
  • contract infer reaches full fidelity — indexes, policy blocks, and @@rls are captured — and signs the database, so introspect-then-verify works end to end on an adopted database. It also infers 1:1 relations from unique indexes. (#29808, #1038)
  • Every error code is documented on an in-repo reference page (221 codes), kept complete by a CI check, and error envelopes carry a docsUrl pointing at their per-code anchor. (#1027, #29806)

Fixes

  • MongoDB write results decode through their type codecs instead of returning raw wire values. (#29879)
  • The Postgres runtime driver serializes queries per pinned client, fixing interleaved-query failures on a shared connection. (#29839)
  • Mixed-case native-enum casts are quoted, so PascalCase enum type names survive Postgres case-folding. (#1034)
  • Driver cursor streaming runs inside an explicit transaction, fixing dropped-portal failures under load. (#1017)
  • Published type declarations name only dependencies a consumer will actually have installed. (#29862)
7.9.1

7.9.1

3 weeks ago

Today, we're issuing a patch release to resolve a security advisory in a transitive dependency of Prisma CLI (via @prisma/dev).

This fixes https://github.com/prisma/prisma/issues/29780.

It does not actually affect @prisma/dev or Prisma CLI so no urgent action is required, but it is recommended to upgrade nevertheless to avoid false positives from security scanners.

7.9.0

7.9.0

1 month ago

Today, we are excited to share the 7.9.0 stable release 🎉

🌟 Star this repo for notifications about new releases, bug fixes & features — or follow us on X!

Highlights

ORM

Tab completions for the Prisma CLI

Typing out CLI commands from memory is now optional. Prisma ships shell tab completions for bash, zsh, fish, and PowerShell, covering commands, subcommands, options, flags, and even option values.

Setting it up. Most projects run Prisma through a package manager, so completions are enabled through @bomb.sh/tab's package-manager integration — install it once, then source the completion for your package manager and shell:

# 1. Install @bomb.sh/tab globally
npm install -g @bomb.sh/tab

# 2. Wire up your package manager + shell (pnpm shown; swap in npm / yarn / bun):
echo 'source <(tab pnpm zsh)'  >> ~/.zshrc            # zsh
echo 'source <(tab pnpm bash)' >> ~/.bashrc           # bash
tab pnpm fish > ~/.config/fish/completions/pnpm.fish  # fish
tab pnpm powershell > ~/.tab-pnpm.ps1                 # PowerShell (then dot-source it from $PROFILE)

@bomb.sh/tab delegates to any locally-installed CLI that ships completions, so pnpm prisma <TAB>, pnpm exec prisma <TAB>, yarn prisma <TAB>, and bun x prisma <TAB> all complete Prisma's commands, options, and values — no per-project setup. (npx and bunx don't support completion themselves; use npm exec and bun x.)

If instead you have Prisma installed globally on your PATH, source its own completion directly: source <(prisma complete zsh) (or the bash / fish / powershell variant).

This is built on @bomb.sh/tab, the same completion library that powers other CLIs in the ecosystem — including Cloudflare, Nuxt, and Vitest — so the package-manager completions you enable for Prisma work for those tools too. A wonderful community contribution from @AmirSa12 (#28351) — thank you!

https://github.com/user-attachments/assets/1f916a60-ee4d-40be-bb7d-74035d48ca83

Prisma ORM, ready for AI agents

Coding agents are now a first-class audience for Prisma, and 7.9.0 brings the first wave of work to make Prisma projects safe and productive for them to work in.

Agent skills installed with prisma init (#29689)

prisma init now installs the prisma/skills catalog into freshly scaffolded projects. Agents such as Claude Code, Cursor, Codex, and Windsurf start out with current, version-relevant Prisma knowledge instead of relying on whatever happened to be in their training data. The install is best-effort and never blocks scaffolding; opt out at any time with --no-skills.

npx prisma@latest init

prisma init scaffolds a project and installs the Prisma agent skills catalog

A safer default around destructive commands (#29684, #29691, #29713)

Prisma's AI safety checkpoint refuses to run destructive commands when it detects that an AI agent is at the keyboard, unless the user has given explicit consent. In this release we:

  • Broadened agent detection to cover today's landscape — Codex CLI (now on Linux as well as macOS), Qwen Code, GitHub Copilot CLI, OpenCode, Cline, Goose, Amp, Crush, Augment Code, Antigravity, Replit Agent, and Devin — plus generic AI_AGENT / AGENT conventions so future agents are caught without a code change.
  • Extended the guard to db push --accept-data-loss, which previously bypassed the checkpoint even though it can drop data.
  • Removed the migrate-reset tool from the prisma mcp server entirely — resetting a database drops it, and that is not an operation an agent should be handed as a first-class tool. An agent that needs a reset must run the CLI, where the checkpoint applies.

Bug Fixes

Many of the fixes below are community contributions — thank you to everyone who reported and fixed these!

Prisma Client

  • Fixed a severe TypeScript performance regression introduced in Prisma 7: restoring the OmitOpts generic default lets tsc reuse cached type instantiations again, bringing type-checking on large schemas back from minutes to seconds (#29592, from @nfl1ryxditimo12).
  • The XOR type helper now rejects primitive values such as data: 5, which were previously accepted at compile time even though the runtime rejected them (#29735, from @kyungseopk1m).
  • $queryRaw and $executeRaw now fail fast with a clear validation error when passed an invalid Date, instead of silently serializing it as null and corrupting the value sent to the database (#29697, from @jibin7jose).
  • The generated client is no longer corrupted by a /// documentation comment that contains a */ sequence; the comment terminator is now escaped when doc comments are emitted, in both the TypeScript and JavaScript generators (#29736, from @kyungseopk1m).
  • Improved the runtime and TypeScript error messages shown when a driver adapter is missing from the PrismaClient constructor; both now include a copy-pasteable example and a link to the driver adapters docs (#29624).
  • Unmapped database errors from driver adapters now surface as a user-facing P2039 (PrismaClientKnownRequestError) carrying the original code and message, instead of an opaque failure, which keeps schema-drift-style problems debuggable (#29512).
  • The prisma-client-js generator no longer emits a stray undefined statement when generating from a schema that declares only enums or types and no models (#29738, from @kyungseopk1m).
  • Fixed a connection leak when an interactive transaction times out (maxWait) while it is still starting: the discarded transaction now sends an explicit ROLLBACK before the connection is returned to the pool, instead of releasing it mid-transaction. Previously, on adapters like @prisma/adapter-pg and @prisma/adapter-neon, the next query to reuse that connection could fail with there is already a transaction in progress — or silently commit the leaked transaction's work (#29727, from @lazerg).

CLI

  • prisma validate (and other schema-loading commands) no longer hangs forever on a multi-file schema whose directories contain a symlink cycle, and no longer reports the same file twice when a directory is reachable under two spellings (e.g. /tmp/private/tmp on macOS) (#29740, from @kyungseopk1m).
  • On Windows, engine binaries are now cached in a stable, user-level directory (%APPDATA%\Prisma) instead of a cwd-relative node_modules\.cache, which eliminated duplicate cache directories and the bloated Serverless/Docker bundles they caused (#29730, from @santichausis; closes #22574, #6670, #11577).

Driver Adapters

  • @prisma/adapter-pg, @prisma/adapter-neon, @prisma/adapter-ppg: Reading a Bytes column no longer emits Node.js' DEP0005 deprecation warning, thanks to an upstream postgres-bytea bump (#29538, from @kolia-zamnius).
  • @prisma/adapter-ppg: ColumnNotFound (P2022) errors now parse both quoted and unquoted PostgreSQL column names, including identifiers containing spaces, matching the fix previously applied to adapter-pg (#29737, from @kyungseopk1m).
  • @prisma/adapter-mssql: Setting a Bytes? (@db.VarBinary) field to null no longer fails with an implicit-conversion error; the adapter now sends the parameter typed as VarBinary instead of letting SQL Server default it to nvarchar (#29630, from @AnupamKumar-1).

Schema Engine

  • prisma migrate status now reports a rolled-back migration that still exists on disk as unapplied, instead of incorrectly treating the schema as up to date (prisma/prisma-engines#5817, from @goutamadwant).
  • Primary-key constraint renames are now rendered as separate ALTER TABLE statements on PostgreSQL, avoiding a database error when a single table has multiple changes in one migration (prisma/prisma-engines#4906, from @eruditmorina).

Security

  • Resolved the hono security advisories at their source: @prisma/dev was updated to a version that no longer depends on hono at all, so the CLI is no longer exposed to those advisories through that path. We also patched moderate-severity advisories in ajv and uuid across production dependencies (#29514).
  • Hardened the Prisma Platform credentials file (~/.config/prisma-platform/auth.json) and its directory to 0o600 / 0o700 so OAuth tokens are no longer world-readable, bringing Prisma in line with the GitHub, AWS, and Google Cloud CLIs (#29568, from Jaeyoung Yun).
  • Bumped the openssl crate in the schema engine binaries from 0.10.74 to 0.10.81 (prisma/prisma-engines#5815).

Prisma Studio

The bundled Prisma Studio moves from 0.27.3 to 0.33.0 (#29720), gathering up everything shipped in the Studio releases in between.

Migrations view

Studio can now visualise your migration history. This view is powered by Prisma Next — the next major version of Prisma ORM, a full TypeScript rewrite (available now in Early Access) that keeps the schema-first workflow and model-first queries you know, but treats your schema as a versioned, inspectable contract instead of compiling it into a heavy generated client. Prisma Next records every migration and its contract snapshots in the database, and Studio reads them to draw the timeline and diff below. Databases managed with classic Prisma Migrate don't carry this ledger, so the view simply stays hidden there.

When the connected database has a Prisma Next migration ledger, a Migrations entry appears in the sidebar: a newest-first timeline of every applied migration with its name, apply time, operation count, and compact chips summarizing what changed (+2 models, ~2 models +3 fields, +1 model, …). Selecting a migration opens a visual, FigJam-style diff canvas — added, removed, and changed models as colour-coded cards (NEW / UPDATED / UNCHANGED) with per-field before → after details, enum cards, and relation edges — next to a SQL panel of the executed statements and a Prisma-schema line diff. Switching migrations morphs the canvas rather than rebuilding it.

The Studio Migrations view: walking a Prisma Next migration history, the diff canvas morphing between migrations

<!-- On publishing: drag wip/demos/prisma-studio-migrations.webp into the GitHub release editor so it becomes a user-attachments URL. -->

Prisma Streams browser

Studio gains first-class support for Prisma Streams: a dedicated stream browser, live stream aggregations, stream diagnostics, routing-key browsing, and a WAL-history handoff straight from your tables, plus richer stream request observability with concise event-log and OpenTelemetry span summaries.

Working with SQL

  • SQL execution, linting, and navigation are now schema-aware: unqualified identifiers resolve against the schema you've selected instead of always falling back to the adapter's default schema.
  • SQL result visualizations are rendered with Studio-owned chart configuration, and there's an optional Queries view backed by query-insights snapshots.
  • Added copy actions to the Query Details view.

Fixes

  • Fixed editing PostgreSQL text-array cells when queries are compiled with inline values.
  • Avoided cancelling and repeating introspection requests when Studio first mounts, removing duplicate startup work.

Thanks to our contributors

A heartfelt thank you to the community members whose contributions shaped this release:

@AmirSa12, @kyungseopk1m, @nfl1ryxditimo12, @jibin7jose, @santichausis, @kolia-zamnius, @goutamadwant, @eruditmorina, @lazerg, @AnupamKumar-1, @Swapanrishi, @anupamme, and @oyi77.

Prisma Compute is now in public beta

"Push code, it runs." Prisma Compute — managed hosting for TypeScript apps that run right next to your database — is now available in public beta, and free to use while the beta lasts.

Compute deploys your app as a long-lived process on Bun, colocated with your Prisma Postgres database, so there are no cold starts, no request timeouts, and no separate hosting vendor to wire up. It's a fit for REST and GraphQL APIs, full-stack apps, streaming and gRPC, and the long-running, stateful AI agents that keep connections open and hold in-process caches — "self-hosting, without the painful parts".

  • Push-to-deploy from the CLI or via GitHub integration. Every deployment is an immutable, versioned release with its own preview URL, and rolling back is simply promoting a previous version.
  • Branch-based environments — each branch gets its own app and database, so you can preview a change before promoting it to production.
  • Auto-wires with Prisma Postgres (or bring any database), with automatic health checks and self-recovery.
  • Custom domains — point a single CNAME at Prisma and Compute provisions and renews the TLS certificate for you, with no manual certificate uploads or private-key handling.

With Prisma ORM for type-safe data access, Prisma Postgres for the managed database, and now Prisma Compute for hosting, the whole stack lives in one place. Read the full story in the Prisma Compute blog series.

Enterprise support

Thousands of teams use Prisma and many of them already tap into our Enterprise & Agency Support Program for hands-on help with everything from schema integrations and performance tuning to security and compliance.

With this program you also get priority issue triage and bug fixes, expert scalability advice, and custom training so that your Prisma-powered apps stay rock-solid at any scale. Learn more or join: https://prisma.io/enterprise.

7.8.0

7.8.0

3 months ago

Today, we are excited to share the 7.8.0 stable release 🎉

🌟 Star this repo for notifications about new releases, bug fixes & features — or follow us on X!

Highlights

ORM

Features

Prisma Client

  • Added a queryPlanCacheMaxSize option to the PrismaClient constructor for fine-grained control over the query plan cache. Pass 0 to disable the cache entirely, or omit it to use the default cache size. A larger value can improve performance in applications that execute many unique queries, while a smaller one can reduce memory usage. (#29503)

Bug Fixes

Prisma Client

  • Fixed an equality filter panic and incorrect ::jsonb cast when filtering on PostgreSQL JSON list columns. Queries using where: { jsonListField: { equals: [...] } } no longer panic with a type mismatch or emit invalid SQL. (prisma/prisma-engines#5804)
  • Fixed case-insensitive JSON field filtering (mode: insensitive), allowing where: { jsonField: { equals: "...", mode: "insensitive" } } to work correctly. (prisma/prisma-engines#5806)
  • Fixed incorrect parameterization of enum values that have a custom database name set via @map. (#29422)
  • Fixed a database parameter limit check (P2029), which could incorrectly reject or miss over-limit queries. (#29422)
  • Fixed a regression that caused missing SQL Server VARCHAR casts for parameterized values. (prisma/prisma-engines#5801)

Schema Engine

  • Fixed a misleading error message in prisma migrate diff that referenced the --shadow-database-url CLI flag, which was removed in Prisma 7. (#29455)
  • Fixed prisma migrate dev (and shadow database migration replay in general) failing with CREATE INDEX CONCURRENTLY cannot run inside a transaction block when a migration contained concurrent index creation statements on PostgreSQL. (prisma/prisma-engines#5799)
  • Fixed PostgreSQL introspection silently dropping sequence defaults when the database returns the schema-qualified form pg_catalog.nextval('sequence_name'::regclass) instead of the bare nextval(...). Columns backed by sequences now correctly appear as @default(autoincrement()) in the Prisma schema in all cases. (prisma/prisma-engines#5802)

Driver Adapters

  • @prisma/adapter-d1: Savepoint operations (createSavepoint, rollbackToSavepoint, releaseSavepoint) now silently no-op with debug logging instead of executing SQL statements, consistent with how the D1 adapter already treats top-level transactions. (#29499)

Open roles at Prisma

Interested in joining Prisma? We're growing and have several exciting opportunities across the company for developers who are passionate about building with Prisma. Explore our open positions on our Careers page and find the role that's right for you.

Enterprise support

Thousands of teams use Prisma and many of them already tap into our Enterprise & Agency Support Program for hands-on help with everything from schema integrations and performance tuning to security and compliance.

With this program you also get priority issue triage and bug fixes, expert scalability advice, and custom training so that your Prisma-powered apps stay rock-solid at any scale. Learn more or join: https://prisma.io/enterprise.

7.7.0

7.7.0

4 months ago

Today, we are excited to share the 7.7.0 stable release 🎉

🌟 Star this repo for notifications about new releases, bug fixes & features — or follow us on X!

Highlights

ORM

prisma bootstrap command

A new prisma bootstrap command (#29374, #29424) sequences the full Prisma Postgres setup into a single interactive flow. It detects the current project state and runs only the steps that are needed:

  1. Init or scaffold — In an empty directory, offers a choice of 10 starter templates (Next.js, Express, Hono, Fastify, Nuxt, SvelteKit, Remix, React Router 7, Astro, NestJS) from prisma-examples. In an existing project without a schema, runs prisma init.
  2. Link — Authenticates via the browser and connects to a Prisma Postgres database. Skips if already linked.
  3. Install dependencies — Detects the package manager and offers to install missing @prisma/client, prisma, and dotenv.
  4. Migrate — Runs prisma migrate dev if the schema contains models.
  5. Generate — Runs prisma generate.
  6. Seed — Runs prisma db seed if a seed script is configured.

Each side-effecting step prompts for confirmation. Re-running the command skips already-completed steps.

Basic usage

npx prisma@latest bootstrap

With a starter template

npx prisma@latest bootstrap --template nextjs

Non-interactive (CI)

npx prisma@latest bootstrap --api-key "$PRISMA_API_KEY" --database "db_abc123"

Open roles at Prisma

Interested in joining Prisma? We're growing and have several exciting opportunities across the company for developers who are passionate about building with Prisma. Explore our open positions on our Careers page and find the role that's right for you.

Enterprise support

Thousands of teams use Prisma and many of them already tap into our Enterprise & Agency Support Program for hands-on help with everything from schema integrations and performance tuning to security and compliance.

With this program you also get priority issue triage and bug fixes, expert scalability advice, and custom training so that your Prisma-powered apps stay rock-solid at any scale. Learn more or join: https://prisma.io/enterprise.

6.19.3

6.19.3

4 months ago

Today, we are issuing a 6.19.3 patch release in the Prisma 6 release line. It updates the effect dependency to resolve a security vulnerability.

Changes: https://github.com/prisma/prisma/pull/29416

7.6.0

7.6.0

4 months ago

Today, we are excited to share the 7.6.0 stable release 🎉

🌟 Star this repo for notifications about new releases, bug fixes & features — or follow us on X!

Highlights

ORM

Features

CLI

  • Added a prisma postgres link command that connects a local project to a Prisma Postgres database. This is the first command in a new prisma postgres command group for managing Prisma Postgres databases directly from the CLI. (#29352)

Driver Adapters

  • @prisma/adapter-pg: Added a statementNameGenerator option that accepts a custom prepared statement name generator to allow users to leverage pg statement caching (#29395)
  • @prisma/adapter-pg: Added support for usage of connection strings directly in the constructor for improved ergonomics (#29287)
  • @prisma/adapter-mariadb: Added a useTextProtocol option in the constructor to toggle between text and binary protocols (#29392)

Bug Fixes

Prisma Client

  • Disabled caching of createMany queries to avoid cache bloat and potential Node.js crashes in bulk operations (#29382)
  • Made NowGenerator lazy to avoid synchronous new Date() calls, fixing Next.js "dynamic usage" errors in cached components (#28724)
  • Fixed missing export of Get<Model>GroupByPayload type in the new prisma-client generator, making it accessible for TypeScript usage (#29346)

CLI

  • Added streaming parsing with automatic fallback to handle Prisma schemas that produce extremely large intermediate strings (>500MB) that hit V8's string limits (#29377)

Driver Adapters

  • @prisma/adapter-pg: Relaxed the @types/pg version constraint to ^8.16.0 for compatibility with newer PostgreSQL type definitions (#29390)
  • @prisma/adapter-pg: Corrected error handling for ColumnNotFound errors to correctly extract column names from both quoted and unquoted PostgreSQL error messages (#29307)
  • @prisma/adapter-mariadb: Modified the adapter to disable mariadb statement caching by default to address a reported leak (#29392)

Prisma Studio

We’re continuing our work to improve Prisma Studio with more features being added.

Dark Mode

Need we say more? You’ve all asked for it, and it’s back.

https://github.com/user-attachments/assets/214149dd-5dd3-4295-9fa3-0da3f8d28197

Copy as markdown

Now, you can copy one or more rows as either CSV or Markdown

<img width="1888" height="672" alt="CleanShot 2026-03-11 at 16 04 09@2x" src="https://github.com/user-attachments/assets/402b4c77-08ac-4c2d-b61a-0135eb42a9af" />

Multi-cell editing

This is big one, something that folks have been asking for. Now, it’s possible to edit multiple cells while inspecting your database. If you make any changes, you’ll be prompted to either save or discard them. This makes manually adding new rows much easier to accomplish.

Back relations

If your data references another table, Prisma Studio now links to the related records, making it easy to inspect them. This makes traversing your database much simpler.

https://github.com/user-attachments/assets/4977a926-413b-495f-b651-b7554eefea04

Generative SQL with AI

If you need to inspect your database, instead of manually writing the SQL you may need, you can use natural language and AI to generate the appropriate SQL statements.

https://github.com/user-attachments/assets/e57c0afb-c3ed-471b-b55a-42395a134863

Open roles at Prisma

Interested in joining Prisma? We’re growing and have several exciting opportunities across the company for developers who are passionate about building with Prisma. Explore our open positions on our Careers page and find the role that’s right for you.

Enterprise support

Thousands of teams use Prisma and many of them already tap into our Enterprise & Agency Support Program for hands-on help with everything from schema integrations and performance tuning to security and compliance.

With this program you also get priority issue triage and bug fixes, expert scalability advice, and custom training so that your Prisma-powered apps stay rock-solid at any scale. Learn more or join: https://prisma.io/enterprise.

7.5.0

7.5.0

5 months ago

Today, we are excited to share the 7.5.0 stable release 🎉

🌟 Star this repo for notifications about new releases, bug fixes & features — or follow us on X!

Highlights

ORM

Features

  • Added support for nested transaction rollbacks via savepoints (#21678)

    Adds support for nested transaction rollback behavior for SQL databases: if an outer transaction fails, the inner nested transaction is rolled back as well. Implements this by tracking transaction ID + nesting depth so Prisma can reuse an existing open transaction in the underlying engine, and it also enables using $transaction from an interactive transaction client.

Bug fixes

Driver Adapters

  • Made the adapter-mariadb use the binary MySQL protocol to fix an issue with lossy number conversions (#29285)
  • Made @types/pg a direct dependency of adapter-pg for better TypeScript experience out-of-the-box (#29277)

Prisma Client

  • Resolved Prisma.DbNull serializing as empty object in some bundled environments like Next.js (#29286)
  • Fixed DateTime fields returning Invalid Date with unixepoch-ms timestamps in some cases (#29274)
  • Fixed a cursor-based pagination issue with @db.Date columns (#29327)

Schema Engine

  • Manual partial indexes are now preserved when partialIndexes preview feature is disabled, preventing unnecessary drops and additions in migrations (#5790, #5795)
  • Enhanced partial index predicate comparison to handle quoted vs unquoted identifiers correctly, eliminating needless recreate cycles (#5788)
  • Excluded partial unique indexes from DMMF uniqueFields and uniqueIndexes to prevent incorrect findUnique input type generation (#5792)

Studio

With the launch of Prisma ORM v7, we also introduced a rebuilt version of Prisma Studio. With the feedback we’ve gathered since the release, we’ve added some high requested features to help make Studio a better experience.

Multi-cell Selection & Full Table Search

This release brings the ability to select multiple cells when viewing your database. In addition to being able to select multiple cells, you can also search across your database. You can search for a specific table or for specific cells within that table.

Adobe Express - CleanShot 2026-03-04 at 21 15 08-2

More intuitive filtering

Filtering is now easier to use, and includes an option for raw SQL filters.

CleanShot 2026-03-11 at 11 26 35

And if you are using Studio in Console, you can use ai generated filters: CleanShot 2026-03-11 at 11 28 18

Cmd+k Command Palette

You can now use the keyboard to perform most actions in Studio with the new cmd+k command palette CleanShot 2026-03-11 at 11 30 35

Run raw SQL queries

Another feature we’ve included in Prisma Studio is the ability to run raw SQL queries against your data. There’s a new “SQL” tab in the sidebar that will bring you to page where you can perform any queries against your data. Below, we’re getting all the rows in the “Todo” table.

Adobe Express - Screen Recording 2026-03-10 at 2 30 52 PM-2

Open roles at Prisma

Interested in joining Prisma? We’re growing and have several exciting opportunities across the company for developers who are passionate about building with Prisma. Explore our open positions on our [Careers page](https://www.prisma.io/careers#current) and find the role that’s right for you.

Enterprise support

Thousands of teams use Prisma and many of them already tap into our Enterprise & Agency Support Program for hands-on help with everything from schema integrations and performance tuning to security and compliance.

With this program you also get priority issue triage and bug fixes, expert scalability advice, and custom training so that your Prisma-powered apps stay rock-solid at any scale. Learn more or join: https://prisma.io/enterprise.

7.4.2

7.4.2

5 months ago

Today, we are issuing a 7.4.2 patch release focused on bug fixes and quality improvements.

🛠 Fixes

Prisma Client

  • Fix a case-insensitive IN and NOT IN filter regression (https://github.com/prisma/prisma/pull/29243)
  • Fix a query plan mutation issue that resulted in broken cursor queries (https://github.com/prisma/prisma/pull/29262)
  • Fix an array parameter wrapping issue in push operations (https://github.com/prisma/prisma-engines/pull/5784)
  • Fix Uint8Array serialization in nested JSON fields (https://github.com/prisma/prisma/pull/29268)
  • Fix an issue with MySQL joins that relied on non-strict equality (https://github.com/prisma/prisma/pull/29251)

Driver Adapters

  • @prisma/adapter-mariadb: Update text column detection to check for a binary collation (https://github.com/prisma/prisma/pull/29238)
  • @prisma/adapter-mariadb: Correct relationJoins compatibility check for MariaDB 8.x versions (https://github.com/prisma/prisma/pull/29246)

Schema Engine

  • Fix partial index predicate comparison on PostgreSQL and MSSQL (https://github.com/prisma/prisma-engines/pull/5780)

🙏 Huge thanks to our community

Many of the fixes in this release were contributed by our amazing community members. We're grateful for your continued support and contributions that help make Prisma better for everyone!

7.4.1

7.4.1

6 months ago

Today, we are issuing a 7.4.1 patch release focused on bug fixes and quality improvements.

🛠 Fixes

Prisma Client

  • Fix cursor-based pagination regression with parameterised values (https://github.com/prisma/prisma/pull/29184)
  • Preserve Prisma.skip through query extension argument cloning (https://github.com/prisma/prisma/pull/29198)
  • Enable batching of multiple queries inside interactive transactions (https://github.com/prisma/prisma/pull/25571)
  • Add missing JSON value deserialization for JSONB parameter fields (https://github.com/prisma/prisma/pull/29182)
  • Apply result extensions correctly for nested and fluent relations (https://github.com/prisma/prisma/pull/29218)
  • Allow missing config datasource URL and validate only when needed (https://github.com/prisma/prisma-engines/pull/5777)

Driver Adapters

  • @prisma/adapter-ppg: Handle null values in type parsers for nullable columns (https://github.com/prisma/prisma/pull/29192)

Prisma Schema Language

  • Support where argument on field-level @unique for partial indexes (https://github.com/prisma/prisma-engines/pull/5774)
  • Add object expression and object member support to schema reformatter (https://github.com/prisma/prisma-engines/pull/5776)

🙏 Huge thanks to our community

Many of the fixes in this release were contributed by our amazing community members. We're grateful for your continued support and contributions that help make Prisma better for everyone!

7.4.0

7.4.0

6 months ago

Today, we are excited to share the 7.4.0 stable release 🎉

🌟 Star this repo for notifications about new releases, bug fixes & features — or follow us on X!

Highlights

ORM

Caching in Prisma Client

Today’s release is a big one, as we introduce a new caching layer into Prisma ORM. But why the need for a caching layer?

In Prisma 7, the query compiler runs as a WebAssembly module directly on the JavaScript main thread. While this simplified the architecture by eliminating the separate engine process, it introduced a trade-off: every query now synchronously blocks the event loop during compilation.

For individual queries, compilation takes between 0.1ms and 1ms, which is barely noticeable in isolation. But under high concurrency this overhead adds up and creates event loop contention that affects overall application throughput.

For instance, say we have a query that is run over and over, but is a similar shape:

// These two queries have the same shape:
const alice = await prisma.user.findUnique({ where: { email: 'alice@prisma.io' } })
const bob = await prisma.user.findUnique({ where: { email: 'bob@prisma.io' } })

Prior to v7.4.0, this would be reevaluated ever time the query is run. Now, Prisma Client will extract the user-provided values and replaces them with typed placeholders, producing a normalized query shape:

prisma.user.findUnique({ where: { email: %1 } })   // cache key
                                         ↑
                              %1 = 'alice@prisma.io'  (or 'bob@prisma.io')

This normalized shape is used as a cache key. On the first call, the query is compiled as usual and the resulting plan is stored in an LRU cache. On every subsequent call with the same query shape, regardless of the actual values, the cached plan is reused instantly without invoking the compiler.

We have more details on the impact of this change and some deep dives into Prisma architecture in an upcoming blog post!

Partial Indexes (Filtered Indexes) Support

We're excited to announce Partial Indexes support in Prisma! This powerful community-contributed feature allows you to create indexes that only include rows matching specific conditions, significantly reducing index size and improving query performance.

Partial indexes are available behind the partialIndexes preview feature for PostgreSQL, SQLite, SQL Server, and CockroachDB, with full migration and introspection support.

Basic usage

Enable the preview feature in your schema:

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["partialIndexes"]
}

Raw SQL syntax

For maximum flexibility, use the raw() function with database-specific predicates:

model User {
  id       Int     @id
  email    String
  status   String

  @@unique([email], where: raw("status = 'active'"))
  @@index([email], where: raw("deletedAt IS NULL"))
}

Type-safe object syntax

For better type safety, use the object literal syntax for simple conditions:

model Post {
  id        Int      @id
  title     String
  published Boolean

  @@index([title], where: { published: true })
  @@unique([title], where: { published: { not: false } })
}

Bug Fixes

Most of these fixes are community contributions - thank you to our amazing contributors!

  • prisma/prisma-engines#5767: Fixed an issue with PostgreSQL migration scripts that prevented usage of CREATE INDEX CONCURRENTLY in migrations
  • prisma/prisma-engines#5752: Fixed BigInt precision loss in JSON aggregation for MySQL and CockroachDB by casting BigInt values to text (from community member polaz)
  • prisma/prisma-engines#5750: Fixed connection failures with non-ASCII database names by properly URL-decoding database names in connection strings
  • #29155: Fixed silent transaction commit errors in PlanetScale adapter by ensuring COMMIT failures are properly propagated
  • #29141: Resolved race condition errors (EREQINPROG) in SQL Server adapter by serializing commit/rollback operations using mutex synchronization
  • #29158: Fixed MSSQL connection string parsing to properly handle curly brace escaping for passwords containing special characters

Open roles at Prisma

Interested in joining Prisma? We’re growing and have several exciting opportunities across the company for developers who are passionate about building with Prisma. Explore our open positions on our Careers page and find the role that’s right for you.

Enterprise support

Thousands of teams use Prisma and many of them already tap into our Enterprise & Agency Support Program for hands-on help with everything from schema integrations and performance tuning to security and compliance.

With this program you also get priority issue triage and bug fixes, expert scalability advice, and custom training so that your Prisma-powered apps stay rock-solid at any scale. Learn more or join: https://prisma.io/enterprise.

7.3.0

7.3.0

7 months ago

Today, we are excited to share the 7.3.0 stable release 🎉

🌟 Star this repo for notifications about new releases, bug fixes & features — or follow us on X!

ORM

  • #28976: Fast and Small Query Compilers We've been working on various performance-related bugs since the initial ORM 7.0 release. With 7.3.0, we're introducing a new compilerBuild option for the client generator block in schema.prisma with two options: fast and small. This allows you to swap the underlying Query Compiler engine based on your selection, one built for speed (with an increase in size), and one built for size (with the trade off for speed). By default, the fast mode is used, but this can be set by the user:
generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
  compilerBuild = "fast" // "fast" | "small"
}

We still have more in progress for performance, but this new compilerBuild option is our first step toward addressing your concerns!

  • #29005: Bypass the Query Compiler for Raw Queries Raw queries ($executeRaw, $queryRaw) can now skip going through the query compiler and query interpreter infrastructure. They can be sent directly to the driver adapter, removing additional overhead.

  • #28965: Update MSSQL to v12.2.0 This community PR updates the @prisma/adapter-mssql to use MSSQL v12.2.0. Thanks Jay-Lokhande!

  • #29001: Pin better-sqlite3 version to avoid SQLite bug An underlying bug in SQLite 3.51.0 has affected the better-sqlite3 adapter. We’ve bumped the version that powers @prisma/better-sqlite3 and have pinned the version to prevent any unexpected issues. If you are using @prisma/better-sqlite3 , please upgrade to v7.3.0.

  • #29002: Revert @map enums to v6.19.0 behavior In the initial release of v7.0, we made a change with Mapped Enums where the generated enum would get its value from the value passed to the @map function. This was a breaking change from v6 that caused issues for many users. We have reverted this change for the time being, as many different diverging approaches have emerged from the community discussion.

  • prisma-engines#5745: Cast BigInt to text in JSON aggregation When using relationJoins with BigInt fields in Prisma 7, JavaScript's JSON.parse loses precision for integers larger than Number.MAX_SAFE_INTEGER (2^53 - 1). This happens because PostgreSQL's JSONB_BUILD_OBJECT returns BigInt values as JSON numbers, which JavaScript cannot represent precisely.

    // Original BigInt ID: 312590077454712834
    // After JSON.parse: 312590077454712830 (corrupted!)
    

    This PR cast BigInt columns to ::text inside JSONB_BUILD_OBJECT calls, similar to how MONEY is already cast to ::numeric.

    -- Before
    JSONB_BUILD_OBJECT('id', "id")
    
    -- After
    JSONB_BUILD_OBJECT('id', "id"::text)
    

This ensures BigInt values are returned as JSON strings, preserving full precision when parsed in JavaScript.

Open roles at Prisma

Interested in joining Prisma? We’re growing and have several exciting opportunities across the company for developers who are passionate about building with Prisma. Explore our open positions on our [Careers page](https://www.prisma.io/careers#current) and find the role that’s right for you.

Enterprise support

Thousands of teams use Prisma and many of them already tap into our Enterprise & Agency Support Program for hands-on help with everything from schema integrations and performance tuning to security and compliance.

With this program you also get priority issue triage and bug fixes, expert scalability advice, and custom training so that your Prisma-powered apps stay rock-solid at any scale. Learn more or join: https://prisma.io/enterprise.

6.19.2

6.19.2

7 months ago

Today, we are issuing a 6.19.2 patch release in the Prisma 6 release line. It fixes an issue with Prisma Accelerate support in some edge runtime configurations when the @prisma/client/edge entrypoint is not being used.

Changes:

  • https://github.com/prisma/prisma/pull/28934
7.2.0

7.2.0

8 months ago

Today, we are excited to share the 7.2.0 stable release 🎉

🌟 Star this repo for notifications about new releases, bug fixes & features — or follow us on X!

Highlights

ORM

  • #28830: feat: add sqlcommenter-query-insights plugin
    • Adds a new SQL commenter plugin to support query insights metadata.
  • #28860: feat(migrate): add -url param for db pull, db push, migrate dev
    • Adds a -url flag to key migrate commands to make connection configuration more flexible.
  • #28895: feat(config): allow undefined URLs in e.g. prisma generate
    • Allows certain workflows (such as prisma generate) to proceed even when URLs are undefined.
  • #28903: feat(cli): customize prisma init based on the JS runtime (Bun vs others)
    • Makes prisma init tailor generated setup depending on whether the runtime is Bun or another JavaScript runtime.
  • #28846: fix(client-engine-runtime): make DataMapperError a UserFacingError
    • Ensures DataMapperError is surfaced as a user-facing error for clearer, more actionable error reporting.
  • #28849: fix(adapter-{pg,neon,ppg}): handle 22P02 error in Postgres
    • Improves Postgres adapter error handling for invalid-text-representation errors (22P02).
  • #28913: fix: fix byte upserts by removing legacy byte array representation
    • Fixes byte upsert behavior by removing a legacy byte-array representation path.
  • #28535: fix(client,internals,migrate,generator-helper): handle multibyte UTF-8 characters split across chunk boundaries in byline
    • Prevents issues when multibyte UTF-8 characters are split across chunk boundaries during line processing.
  • #28911: fix(cli): make prisma version --json emit JSON only to stdout
    • Ensures machine-readable JSON output is emitted cleanly to stdout without extra noise.

VS Code Extension

  • #1950: fix: TML-1670 studio connections
    • Resolves issues related to Studio connections, improving reliability for VS Code or language-server integrations.

Open roles at Prisma

Interested in joining Prisma? We’re growing and have several exciting opportunities across the company for developers who are passionate about building with Prisma. Explore our open positions on our [Careers page](https://www.prisma.io/careers#current) and find the role that’s right for you.

Enterprise support

Thousands of teams use Prisma and many of them already tap into our Enterprise & Agency Support Program for hands-on help with everything from schema integrations and performance tuning to security and compliance.

With this program you also get priority issue triage and bug fixes, expert scalability advice, and custom training so that your Prisma-powered apps stay rock-solid at any scale. Learn more or join: https://prisma.io/enterprise.

6.19.1

6.19.1

8 months ago

Today, we are issuing a patch release for Prisma 6 that includes a fix for a diffing bug introduced in Prisma 6.13.1, which led to incorrectly reported empty diffs.

Changes

  • https://github.com/prisma/prisma-engines/pull/5706