Prisma Client is an auto-generated, type-safe and modern JavaScript/TypeScript ORM for Node.js that's tailored to your data. Supports PostgreSQL, CockroachDB, MySQL, MariaDB, SQL Server, SQLite & MongoDB databases.
Last release 2 days ago
01 Sep 2026
Ships fairly regularly
a new release about every 1 weeks
Nearly every release is documented
notes for 60 of the last 60 stable releases
3 versions withdrawn
withdrawn after publishing
7 years old
10657 releases · first in 2020
One column per quarter.
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Today we release the first patch release 2.0.1.
This is the first time that we run our new patch process! And it looks like everything went well 🤗.
prisma introspect got improved so there are fewer false positives that tell users their database is Prisma 1.Nothing published for this version
Nothing published for this version
Nothing published for this version
🎉 Today, we are launching Prisma 2.0 for General Availability! Read the announcement to learn more.
Today's General Availability release features Prisma Client, a type-safe and auto-generated query builder for your database. Thanks to introspection, Prisma Client can be used for existing databases as well.
Note: Prisma Migrate and Prisma Studio are not part of today's release. They're still experimental.
The easiest way to get started is by following the Quickstart (5 min). It is based on a SQLite demo database and doesn't require any setup!
You can also connect Prisma to your own PostgreSQL or MySQL database, either in an existing project or when starting from scratch.
As always, we very much appreciate your feedback! Please don't hesitate to reach out here on GitHub or on Slack if you have any questions, thoughts, or any other kind of feedback about Prisma! 🙌
If you're currently using Prisma 1 and want to upgrade to the new version, you can start by learning about the upgrade process in the docs: How to upgrade 📚
If you have any questions or feedback about the upgrade process, please create a GitHub issue in our new feedback repo. You can also share your personal feedback path with us and we'll try to figure out the best way to upgrade with you!
We're also planning upgrade webinars, where we're demoing the upgrade process for different scenarios (e.g. using prisma-binding, Prisma Client, Nexus, ...). The webinars are currently planned for July, we'll announce the dates soon!
We're hosting another edition of Prisma Day this year and are going fully remote. Join us online for hands-on workshops on June 25th and great talks on June 26th. Some of the speakers include GitHub co-founder Tom Preston-Werner, Netlify CEO Mathias Biilmann Christensen and lots of Prisma folks to tell you the latest about Prisma 2.0.
Nothing published for this version
Today, we are issuing the twenty-fifth Preview release: 2.0.0-preview025 (short: preview025).
prisma2 npm packageWith this release, we're renaming the Prisma 2 CLI npm package from prisma2 to @prisma/cli. Note that you can still invoke the CLI using the prisma2 command!
To upgrade, you first should uninstall the current prisma2 version and then install the @prisma/cli package.
The local installation is generally preferred since it prevents conflicting versions of the same package.
# Uninstall current `prisma2` CLI (`preview024` or earlier)
npm uninstall prisma2
# Install new `prisma2` CLI via `@prisma/cli` npm package
npm install @prisma/cli --save-dev
# Invoke the CLI via `npx`
npx prisma2
# Uninstall current `prisma2` CLI (`preview024` or earlier)
npm uninstall -g prisma2
# Install new `prisma2` CLI via `@prisma/cli` npm package
npm install -g @prisma/cli
# Invoke the CLI via `npx`
npx prisma2
prisma2 --version output changederrorFormat in the PrismaClient constructor now is colorlessprisma2datasource block fail with Error: Schema parsing error: Unexpected token. Expected one of: End of block ("}"), alphanumeric identifiererror: Argument 'value' is missing in attribute '@default'.Error occurred during query validation & transformation:PANIC: Could not parse stored DateTime string: 2009-01-01 00:00:00: ParseError(Invalid) on findMany()thread 'main' panicked at 'Expected ID field ... to be present on the model'@default doesnt work for enumprisma-client-jspretty to colorlessError parsing GraphQL query: query parse error: Parse error at 4:3 Unexpected}[Punctuator]ExpectedName from findMany({}) after introspectionFloat sometimes results on sightly different value written to Postgresundefined from findMany({}) after introspectionprisma-enginesSELECT 1 before every queryIN queries into smaller batchesdbGenerated() for Default valuesmigrateToday, we are issuing the twenty-fourth Preview release: 2.0.0-preview024 (short: preview024).
This release contains major improvements for Prisma Client. It now supports Windows Azure functions. In addition to that, the generated Prisma Client code inside your node_modules directory now is a lot smaller.
Another improvement is a better debugging experience. When setting the DEBUG environment variable (e.g. with export DEBUG="*"), the logging output now contains the names of Prisma Client API calls.
In this release, it's now possible to use relation fields of Prisma models as IDs. In "database-speak", this means that you can now have both a primary key and a foreign key constraint on the same column.
For example, a Movie could always be identified by its Director:
model Movie {
director Director @id
title String
}
model Director {
id Int @id @default(@autoincrement())
name String
}
This is what the corresponding SQL (in SQLite dialect) looks like:
CREATE TABLE "Movie" (
"director" INTEGER NOT NULL ,
"title" TEXT NOT NULL DEFAULT '' ,
PRIMARY KEY ("director"),
FOREIGN KEY ("director") REFERENCES "Director"("id")
);
CREATE TABLE "Director" (
"id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
"name" TEXT NOT NULL DEFAULT ''
);
<details><summary>Expand to view an example for creating Movies and Directors in Prisma Client</summary>
Nested write to create Movie with Director:
// Run inside `async` function
const movie = await prisma.movie.create({
data: {
title: "Hello World",
director: {
create: {
name: "Alice"
}
}
},
})
Nested write to create Director with Movie:
// Run inside `async` function
const director = await prisma.director.create({
data: {
name: "Bob",
movies: {
create: [{
title: "Hello World"
}]
}
},
})
</details>
You can also create a relation to a multi-field ID:
model Movie {
director Director @id @map(["firstName", "lastName"])
title String
}
model Director {
firstName String
lastName String
@@id([firstName, lastName])
}
Note that in this case, the Movie table in the underlying database will actually have two physical columns called firstName and lastName. These are referencing the respective firstName and lastName column on the Director table.
Here is what the above models correspond to in SQL:
CREATE TABLE "Movie" (
"firstName" TEXT NOT NULL ,
"lastName" TEXT NOT NULL ,
"title" TEXT NOT NULL DEFAULT '' ,
PRIMARY KEY ("firstName","lastName"),
FOREIGN KEY ("firstName","lastName") REFERENCES "Director"("firstName","lastName")
);
CREATE TABLE "Director" (
"firstName" TEXT NOT NULL DEFAULT '' ,
"lastName" TEXT NOT NULL DEFAULT '' ,
PRIMARY KEY ("firstName","lastName")
);
In many cases, it might make sense to name the columns on Movie differently. For example, they could be called directorFirstName and directorLastName. This can be achieved via adding the @map attribute to the field:
model Movie {
director Director @id @map(["directorFirstName", "directorLastName"]) @relation(references: [firstName, lastName])
title String
}
model Director {
firstName String
lastName String
@@id([firstName, lastName])
}
Note that in this case you could also omit the @relation attribute, the result would be the same:
model Movie {
director Director @id @map(["directorFirstName", "directorLastName"])
title String
}
model Director {
firstName String
lastName String
@@id([firstName, lastName])
}
In this case, the field names in @map on Movie get matched with the field names in @@id on Director.
Both cases correspond to the following SQL:
CREATE TABLE "Movie" (
"directorFirstName" TEXT NOT NULL ,
"directorLastName" TEXT NOT NULL ,
"title" TEXT NOT NULL DEFAULT '' ,
PRIMARY KEY ("directorFirstName","directorLastName"),
FOREIGN KEY ("directorFirstName","directorLastName") REFERENCES "Director"("firstName","lastName")
);
CREATE TABLE "Director" (
"firstName" TEXT NOT NULL DEFAULT '' ,
"lastName" TEXT NOT NULL DEFAULT '' ,
PRIMARY KEY ("firstName","lastName")
);
<details><summary>Expand to view an example for creating Movies and Directors in Prisma Client</summary>
Nested write to create Movie with Director:
// Run inside `async` function
const movie = await prisma.movie.create({
data: {
title: 'Hello World',
director: {
create: {
firstName: 'Alice',
lastName: 'Allen',
},
},
},
})
Nested write to create Director with Movie:
// Run inside `async` function
const director = await prisma.director.create({
data: {
firstName: 'Bob',
lastName: 'Nolan',
movies: {
create: [
{
title: 'Hello World',
},
],
},
},
})
</details>
You can also create a multi-field ID on a model that contains a relation field:
model Movie {
director Director
title String
@@id([director, title])
}
model Director {
id String @id @default(cuid())
name String
}
This corresponds to the following SQL:
CREATE TABLE "Movie" (
"director" TEXT NOT NULL ,
"title" TEXT NOT NULL DEFAULT '' ,
PRIMARY KEY ("director","title"),
FOREIGN KEY ("director") REFERENCES "Director"("id")
);
CREATE TABLE "Director" (
"id" TEXT NOT NULL ,
"name" TEXT NOT NULL DEFAULT '' ,
PRIMARY KEY ("id")
);
<details><summary>Expand to view an example for creating Movies and Directors in Prisma Client</summary>
Nested write to create Movie with Director:
// Run inside `async` function
const movie = await prisma.movie.create({
data: {
title: 'Hello World',
director: {
create: {
name: 'Alice',
},
},
},
})
Nested write to create Director with Movie:
// Run inside `async` function
const director = await prisma.director.create({
data: {
name: 'Bob',
movies: {
create: [
{
title: 'Hello World 2',
},
],
},
},
})
</details>
You can also define a multi-field ID on a model which contains a relation field that targets a model with a multi-field ID:
model Movie {
director Director
title String
@@id([director, title])
}
model Director {
firstName String
lastName String
@@id([firstName, lastName])
}
This is what the above code translates to in SQL:
CREATE TABLE "Movie" (
"director_firstName" TEXT NOT NULL ,
"director_lastName" TEXT NOT NULL ,
"title" TEXT NOT NULL DEFAULT '' ,
PRIMARY KEY ("director_firstName","director_lastName","title"),
FOREIGN KEY ("director_firstName","director_lastName") REFERENCES "Director"("firstName","lastName")
);
CREATE TABLE "Director" (
"firstName" TEXT NOT NULL DEFAULT '' ,
"lastName" TEXT NOT NULL DEFAULT '' ,
PRIMARY KEY ("firstName","lastName")
);
Similar to the case before, you can also give names to the added columns on Movie by using the @map attributed:
model Movie {
director Director @map(["directorFirstName", "directorLastName"]) @relation(references: [firstName, lastName])
title String
@@id([director, title])
}
model Director {
firstName String
lastName String
@@id([firstName, lastName])
}
And as before you can also omit the @relation attribute in this scenario:
model Movie {
director Director @map(["directorFirstName", "directorLastName"])
title String
@@id([director, title])
}
model Director {
firstName String
lastName String
@@id([firstName, lastName])
}
In both cases, the models correspond to the following tables:
CREATE TABLE "Movie" (
"directorFirstName" TEXT NOT NULL ,
"directorLastName" TEXT NOT NULL ,
"title" TEXT NOT NULL DEFAULT '' ,
PRIMARY KEY ("directorFirstName","directorLastName","title"),
FOREIGN KEY ("directorFirstName","directorLastName") REFERENCES "Director"("firstName","lastName")
);
CREATE TABLE "Director" (
"firstName" TEXT NOT NULL DEFAULT '' ,
"lastName" TEXT NOT NULL DEFAULT '' ,
PRIMARY KEY ("firstName","lastName")
);
<details><summary>Expand to view an example for creating Movies and Directors in Prisma Client</summary>
Nested write to create Movie with Director:
// Run inside `async` function
const movie = await prisma.movie.create({
data: {
title: 'Hello World',
director: {
create: {
firstName: 'Alice',
lastName: 'Allen',
},
},
},
})
Nested write to create Director with Movie:
// Run inside `async` function
const director = await prisma.director.create({
data: {
firstName: 'Bob',
lastName: 'Nolan',
movies: {
create: [
{
title: 'Hello World',
},
],
},
},
})
</details>
MODELGetSelectPayload and MODELGetIncludePayload have been merged into MODELGetPayload. More info here.
prisma2@default include type information@prisma/sdk version in lockstep with prisma2introspect for SQLite returns id as String when it should be IntDEBUG env var)migrateprisma-client-jsprisma-enginescargo test commandint as Integer on SqliteToday, we are issuing the twenty-third Preview release: 2.0.0-preview023 (short: preview023).
This release contains breaking changes, be sure to read the notes below before upgrading!
Because Prisma now supports composite unique constraints, the before and after API for cursor-pagination (which is based on unique fields) also changes. The cursor is now wrapped in an object which might have multiple fields.
Assume you have this Prisma model:
model Post {
id Int @default(autoincrement())
title String @unique
content String?
}
Before
const cursor = 42
const posts = await prisma.post.findMany({
after: cursor
})
After
const cursor = 42
const posts = await prisma.post.findMany({
after: { id: cursor }
})
enabled property in datasource blocksThe enabled property was removed from the datasource blocks.
In this issue, we're lifting a major limitation of Prisma which always required every model to have exactly one primary key constraint. In the Prisma schema, this primary key was represented using the @id attribute.
With this release, you can now have tables:
Read below for more information on each of these new features. Lifting these limitations was a major effort, please be sure to report any bugs or other issues you encounter using these new features!
In previous Prisma versions, there was a hard requirement that every model in your Prisma schema needed to have a single @id field (which maps to a primary key constraint in the underlying database). This requirement is now lifted and your models don't need primary key constraints any more to be compatible with Prisma 2 (they do need at least one unique constraint though).
For example, this data model is now valid:
model Post {
title String @unique
content String?
published Boolean @default(false)
author User?
}
model User {
email String @unique
name String?
posts Post[]
}
As of this release, Prisma supports composite IDs (which map to multi-column primary key constraints in the underlying database). Composite IDs are defined on a "model-level" using the @@id attribute. Here's an example:
model User {
firstName String
lastName String
email String
@@id([firstName, lastName])
}
This also impacts the Prisma Client API and how you're querying for single records, e.g. in findOne, update or delete queries where you need to identify a record by its primary key (or another unique field). These queries take the following type as input:
export type UserWhereUniqueInput = {
firstName_lastName?: FirstNameLastNameCompoundUniqueInput | null
}
export type FirstNameLastNameCompoundUniqueInput = {
firstName: string
lastName: string
}
This means, in order to query for a User record, you need to provide both firstName and lastName fields wrapped inside a firstName_lastName object:
const user = await prisma.user.findOne({
where: {
firstName_lastName: {
firstName: "Jane",
lastName: "Doe"
}
}
})
As of this release, Prisma also supports composite unique constraints (which map to multi-column unique constraints in the underlying database). Composite unique constraints are defined on a "model-level" using the @@unique attribute.
Note: Primary key and unique constraints are very similar but have some differences on the database-level. You can learn more about the differences here.
Here's an example:
model User {
firstName String
lastName String
email String
@@unique([firstName, lastName])
}
This also impacts the Prisma Client API and how you're querying for single records, e.g. in findOne, update or delete queries where you need to identify a record by its primary key (or another unique field). These queries take the following type as input:
export type UserWhereUniqueInput = {
firstName_lastName?: FirstNameLastNameCompoundUniqueInput | null
}
export type FirstNameLastNameCompoundUniqueInput = {
firstName: string
lastName: string
}
This means, in order to query for a User record, you need to provide both firstName and lastName fields wrapped inside a firstName_lastName object:
const user = await prisma.user.findOne({
where: {
firstName_lastName: {
firstName: "Jane",
lastName: "Doe"
}
}
})
Prisma's introspection now reconized DEFAULT constraints that are defined on a column. These constraints are represented in the generated Prisma schema using the @default attribute.
When building a GraphQL server with Prisma Client, it wasn't easy to avoid the n+1 problem with nested queries. This release of Prisma Client optimizes the execution of GraphQL nested queries by batching requests against the database.
prisma2generate --watch brokenOption::unwrap() on a None value.raw template literal API with parameters #1583Option::unwrap() on a None valueError: P4001 The introspected database was empty: undefined url or file if sqlite should be displayed instead of undefined(left == right).raw template literal API with parametersgenerate shows "Downloading ..." every time when a custom binaryTarget is specifiedgenerateprisma-client-js.raw template literal API with parametersJSON.parse(dmmfString) fails on prisma schema with docsnative, Prisma Client automatically resolves rhel-openssl-1.0.x"datamodel.mdl) and client name (Photon JS) in graphic in README need to be updatedprisma-engines@map into account when migrating enum valuesToday, we are issuing the twenty-second Preview release: 2.0.0-preview022 (short: preview022).
This release contains breaking changes, be sure to read the notes below before upgrading!
prisma.raw(sql) (read the API docs)prisma2 init now uses environment variables and creates a .env fileThe following change is only breaking if you're using introspection and are currently using Prisma Client API calls that are referencing a virtual back-relation field. Read on to learn more.
When introspecting a table with a foreign key, Prisma automatically creates a "virtual back-relation" field on the respective Prisma model. Consider the following SQL schema:
CREATE TABLE User (
user_id SERIAL PRIMARY KEY NOT NULL,
name VARCHAR(256),
);
CREATE TABLE Post (
post_id SERIAL PRIMARY KEY NOT NULL,
title VARCHAR(256) NOT NULL,
author_id INTEGER,
FOREIGN KEY (author_id) REFERENCES User(user_id)
);
In previous Prisma 2 preview versions, the resulting Prisma data model after introspection used to be:
model User {
user_id Int @id @default(autoincrement())
posts Post[] // before `preview022`
}
model Post {
post_id Int @id @default(autoincrement())
title String
author User?
}
Notice the posts field which has been added by Prisma. This field does not exist as a column on the database-level, but is a "virtual back-relation" field in the Prisma schema.
With preview022, the pluralization of the virtual back-relation field has been removed. The new introspection result would be:
model User {
user_id Int @id @default(autoincrement())
post Post[] // after `preview022`
}
model Post {
post_id Int @id @default(autoincrement())
title String
author User?
}
.env file changedAs explained in this issue, the path to the default .env file is changed in this Preview version. Before, the Prisma CLI automatically loaded the environment variables from a .env file in the current working directory. This now changes and it only loads them from the directory that contains the schema.prisma file.
Enums in the Prisma schema are now mapped to enums in the underlying database (previously they were represented as strings). This means enum support for SQLite is completely removed since SQLite doesn't support enums.
prisma2warning In order to use "@prisma/client", please install prisma2. You can install it with "npm add -D prisma2" is printed even when prisma2 is installed.raw API@prisma/client@x is not compatible with prisma2@y. Their versions need to be equal., generates anywaygetDatabaseDescription if error consent screen didn't have confirmation.env file next to schema.prisma@@id refers to original field name instead of @map-ped oneintrospect: "Error [ERR_STREAM_DESTROYED]: Cannot call write after a stream was destroyed"generate: "Error: Schema parsing --- thread 'main' has overflowed its stack"id is a String in the schema but an Integer in SQLite.--schema?)introspect command, backup behavior⠋ Introspecting MySQL schema with 1 tables. during introspectionUpsert causes random self-referencing 1:1 relations to breakprisma-client-jsnextTick - based batchingundefined and Errorgenerate tells me to install wrong Prisma Client packagenull in ENUM filtersmigrate--help does not need --experimental for main migrate, does for migrate saveprisma-enginesToday, we are issuing the twenty-first Preview release: 2.0.0-preview021 (short: preview021).
This release contains breaking changes, be sure to read the notes below before upgrading!
⚠️ If you're using Prisma together with GraphQL Nexus and nexus-prisma, check out the additional release notes of nexus-prisma: https://github.com/prisma-labs/nexus-prisma/releases/tag/0.9.0
The property on the PrismaClient that exposes CRUD operations per model used to be lowercased and pluralized, the pluralization of that property is now removed.
For example, for a model User you'd access a CRUD operation via the generated prisma.users property, as in prisma.users.findMany(). As of preview021, the pluralization has been removed and the property is called after the model (but lowercased), so it would now be prisma.user.findMany().
Here are few more examples showing how the calls to your PrismaClient instance must be adjusted:
Prisma schema
model User {
id Int @id @default(autoincrement())
name String
}
Generated Prisma Client API
const prisma = new PrismaClient()
// CRUD operations are exposed via:
- // prisma.users
+ // prisma.user
// findMany
- const users = await prisma.users.findMany()
+ const users = await prisma.user.findMany()
// findOne
- const user = await prisma.users.findOne({ where: { id: 1 }})
+ const user = await prisma.user.findOne({ where: { id: 1 }})
// create
- const user = await prisma.users.create({ data: { name: "Alice" }})
+ const user = await prisma.user.create({ data: { name: "Alice" }})
// and so on ...
Besides many small fixes, Prisma Client JS now uses JSDoc to bring API documentation to your fingertips as you write code in your editor:
prisma2generate --help message to Generate artifacts (e.g. Prisma Client)Prisma is a modern DB toolkit to query, migrate and model your databaseprisma2 migrate docsundefined in prisma2 init --help outputprisma introspectprisma2 init fails in Yarn Workspacesprisma-client-jsfindOne without argspg-bouncerset for scalarList is not provided or it is set to []postinstall script of this package fails if using env var in my schemamigrateprisma-engine@default(autoincrement())@map for relation fields that use compound referencesToday, we are issuing the twentieth Preview release: 2.0.0-preview020 (short: preview020).
This release has a number of major and breaking changes, be sure to read the notes below before upgrading!
The most important changes are:
migrate (formerly lift) subcommands behind an --experimental flagprisma2 dev commandprisma2 init wizardonDelete has been removed from the @relation attributeTo see how the changes affect an application, check out the updated examples.
⚠️ If you're using Prisma together with GraphQL Nexus and nexus-prisma, check out the additional release notes of nexus-prisma: https://github.com/prisma-labs/nexus-prisma/releases/tag/0.7.0
Aside from the renaming throughout all our content resources, this change is breaking the generator definition in your Prisma schema. Instead of using photonjs as the provider of your generator, you now need to use prisma-client-js:
generator client {
- provider = "photonjs"
+ provider = "prisma-client-js"
}
The Prisma Client's npm package has also been renamed. Instead of installing @prisma/photon, you're now using @prisma/client:
- npm install @prisma/photon
+ npm install @prisma/client
Finally, the way how you import Prisma Client in your code and instantiate it needs to be adjusted too:
- import { Photon } from '@prisma/photon'
+ import { PrismaClient } from '@prisma/client'
+ // const { PrismaClient } = require('@prisma/client')
- const photon = new Photon
+ const prisma = new PrismaClient()
Note that the former photonjs repo is now called prisma-client-js. We also removed the former Photon.js website on https://photonjs.prisma.io and are redirecting it to these release notes.
<details><summary>Why was Photon.js renamed?</summary> <br />
We renamed Photon.js in an effort to make Prisma simpler. Instead of using abstract names for the Prisma tools, we've decided to use descriptive names for the different parts of Prisma to make it easier for newcomers to understand what each of our tools does.
</details>
--experimental flagPrisma's lift subcommand has been renamed to migrate:
- prisma2 lift save
- prisma2 lift up
+ prisma2 migrate save
+ prisma2 migrate up
The initial launch of Prisma 2 in February will include only Prisma Client, but not yet Prisma's migration tooling. To anticipate this split, all migration-related functionality of the prisma2 CLI now requires an explicit opt-in via an --experimental flag:
prisma2 migrate save --experimental
prisma2 migrate up --experimental
Note that the former lift repo is now called migrate. We also removed the former Lift website on https://lift.prisma.io and are redirecting it to these release notes.
<details><summary>Why was Lift renamed?</summary> <br />
We renamed Lift in an effort to make Prisma simpler. Instead of using abstract names for the Prisma tools, we've decided to use descriptive names for the different parts of Prisma to make it easier for newcomers to understand what each of our tools does.
</details>
prisma2 devThe prisma2 dev command has been removed from the Prisma 2 CLI. If you want to automatically re-generate Prisma Client upon a schema change, you can now add the --watch flag on the generate command:
prisma2 generate --watch
<details><summary>Why was <code>prisma2 dev</code> removed?</summary> <br />
The prisma2 dev command was removed because it was using Prisma's migration functionality under the hood. Since migrations are considered experimental as of this release, we wanted to make sure that the main Prisma worfklows are not using them any more. Note that in the future we will provide an even better experience for developers who liked the quick turnaround time of prisma2 dev.
</details>
prisma2 init wizardThe prisma2 init command has been simplified. It now only outputs a basic schema.prisma file with some helpful comments that explain potential next steps. A typical "getting started" flow now looks as follows:
prisma2 init to create an empty Prisma schema file.url of the datasource block inside the Prisma schema.prisma2 introspect to test the connection and obtain your data model.prisma2 generate to generate Prisma Client.You can then start using Prisma Client in your application:
import { PrismaClient } from 'prisma-client-js'
// or const { PrismaClient } = require('prisma-client-js')
const prisma = new PrismaClient()
Learn more in the updated "Getting Started"-guide.
If you want to get started with a new project instead of using an existing database, check out the available examples.
<details><summary>Why was the interactive <code>prisma2 init</code> wizard removed?</summary> <br />
The interactive prisma2 init wizard was a very ambitious command to support developers in setting up their Prisma-based projects. While it helped some developers get started with an initial setup, it also showed to be very complex, confusing and difficult to maintain.
We therefore decided to remove the wizard and opted for a simpler version of prisma2 init that just sets up an initial Prisma schema file for you.
</details>
To improve the Prisma tools, we've created a new telemetry endpoint. This endpoint is pinged by the prisma2 CLI upon the invokation of any command. Note that after the endpoint got pinged once, the pinging is paused for 48 hours before the next ping is sent from a command invokation. Learn more about the new telemetry server and the data it's sending in the docs.
You can opt-out of this behavior by setting the CHECKPOINT_DISABLE environment variable to 1, e.g.:
export CHECKPOINT_DISABLE=1
onDelete has been removed from the @relation attributeWhile not causing an error, the onDelete argument on the @relation attribute didn't have any effect (i.e., it hadn't been implemented yet). To make the API surface simpler, we removed it from the Prisma schema for now.
We also decided to rename the Prisma Framework to Prisma 2 (or just "Prisma") again. The main reason for this is that many developers got confused about the term "framework" and misinterpreted it as a "web application framework" when it was supposed to refer to a "database framework". To prevent this confusion in the future, we decided to remove the "Framework"-part from its name.
As of now, we're still mainly referring to it as Prisma 2. After the initial launch in February, Prisma 2 will be referred to as just "Prisma".
prisma2init, Introspection: Tells me that schema is not empty, does not even exist thoughinit: Starter Kit flows only show empty databasesinit: Input is not disabled while connecting to databaseprisma2 generate keeps downloading query engine (or at least tells me it does)init: Back button is not workingprisma2 init, first step is labeled "Languages for starter kits"init: Wrong "Back" detailBlank project -> ... -> Demo script optionprisma2 init navigation infinite loopprisma2 generate tries to install @prisma/photon even in folder without package.jsonnot found page--url? is not accepted as character in column name( is not accepted as character in column name- is not accepted as character in column name/ is not accepted as character in column nameinitdevnpm add--help to print help in prisma2 initprisma-client-jsnew Photon in the lambda function context stops the engineorderBy: null many query*GetSelectPayload and *GetIncludePayload utility typesmigrate--help argument to print help on prisma2 devprisma-engineToday, we are issuing the ninth Beta release: 2.0.0-beta.9 (short: beta.9).
ORWe used to allow this syntax:
const orIncorrect = await prisma.post.findMany({
orderBy: {
id: 'asc'
},
where: {
OR: {
title: {
equals: "Prisma makes databases easy"
},
authorId: {
equals: 2
}
}
}
});
However, the thing that we want is this:
const orCorrect = await prisma.post.findMany({
orderBy: {
id: 'asc'
},
where: {
OR: [{
title: {
equals: "Prisma makes databases easy"
},
}, {
authorId: {
equals: 2
}
}]
}
})
So only the array syntax makes sense, therefore we also only allow that from now on.
prismaprisma-client-jsvscodeprisma-enginesuniqueIndexes to Model in DMMFdefault for Field in DMMF Huge thanks to @Sytten for helping!
Today, we are issuing the eighth Beta release: 2.0.0-beta.8 (short: beta.8).
.raw into .queryRaw and .executeRawWhen dealing with raw SQL queries, there are two things we care about - the "return payload", which is being calculated by the SELECT statement we use and the number of affected rows - if we for example do an UPDATE query.
Until now, Prisma Client decided under the hood with a heuristic, when to return the number of affected rows and when to return the result data.
This heuristic broke if you wanted the opposite of what the heuristic returned.
That means that the decision has to be made by the developer using Prisma Client instead.
Therefore, we remove the raw command and replace it with executeRaw and queryRaw.
So what does return what?
executeRaw returns the number of affected rowsqueryRaw returns the result dataThe heuristic used to return the data for SELECT statements. So if you upgrade to Beta 8, you need to use queryRaw for your SELECT statements and executeRaw for all SQL queries, which mutate data.
The rule of thumb is: Do not use executeRaw for queries that return rows.
In Postgres, it will work to use executeRaw('SELECT 1), however, SQLite will not allow that.
prismanpx prisma generate issue if working directory contains spacesstring.prisma-client-jsHuge thanks to @Sytten, @merelinguist for helping!
Today, we are issuing the seventh Beta release: 2.0.0-beta.7 (short: beta.7).
Prisma Client's pagination has been simplified a lot!
first, last, before, after arguments.cursor and take arguments.skip argument unchanged.The take argument replaces first and last.
firstprisma.user.findMany({
first: 10
})
// becomes
prisma.user.findMany({
take: 10
})
lastprisma.user.findMany({
last: 10
})
// becomes
prisma.user.findMany({
take: -10
})
beforeprisma.user.findMany({
before: "someid"
first: 10
})
// becomes
prisma.user.findMany({
cursor: "someid"
take: -10
skip: 1
})
afterprisma.user.findMany({
after: "someid"
first: 10
})
// becomes
prisma.user.findMany({
cursor: "someid"
take: 10
skip: 1
})
The record specified with cursor is now included in the results, making skip: 1 necessary if you want to preserve the previous before / after semantics.
This diagram illustrates how the pagination works:
cursor: 5
skip: 0 or undefined
│
│
│
▼
┌───┐┌───┐┌───┐┏━━━┓┏━━━┓┌───┐┌───┐┌───┐┌───┐┌───┐
│ 1 ││ 2 ││ 3 │┃ 4 ┃┃ 5 ┃│ 6 ││ 7 ││ 8 ││ 9 ││10 │
└───┘└───┘└───┘┗━━━┛┗━━━┛└───┘└───┘└───┘└───┘└───┘
◀────────
take: -2
cursor: 5
skip: 1
│
│
│
▼
┌───┐┌───┐┏━━━┓┏━━━┓┌───┐┌───┐┌───┐┌───┐┌───┐┌───┐
│ 1 ││ 2 │┃ 3 ┃┃ 4 ┃│ 5 ││ 6 ││ 7 ││ 8 ││ 9 ││10 │
└───┘└───┘┗━━━┛┗━━━┛└───┘└───┘└───┘└───┘└───┘└───┘
◀────────
take: -2
cursor: 5
skip: 2
│
│
│
▼
┌───┐┏━━━┓┏━━━┓┌───┐┌───┐┌───┐┌───┐┌───┐┌───┐┌───┐
│ 1 │┃ 2 ┃┃ 3 ┃│ 4 ││ 5 ││ 6 ││ 7 ││ 8 ││ 9 ││10 │
└───┘┗━━━┛┗━━━┛└───┘└───┘└───┘└───┘└───┘└───┘└───┘
◀────────
take: -2
cursor: 5
skip: 0 or undefined
│
│
│
▼
┌───┐┌───┐┌───┐┌───┐┏━━━┓┏━━━┓┏━━━┓┌───┐┌───┐┌───┐
│ 1 ││ 2 ││ 3 ││ 4 │┃ 5 ┃┃ 6 ┃┃ 7 ┃│ 8 ││ 9 ││10 │
└───┘└───┘└───┘└───┘┗━━━┛┗━━━┛┗━━━┛└───┘└───┘└───┘
──────────▶
take: 3
cursor: 5
skip: 1
│
│
│
▼
┌───┐┌───┐┌───┐┌───┐┌───┐┏━━━┓┏━━━┓┏━━━┓┌───┐┌───┐
│ 1 ││ 2 ││ 3 ││ 4 ││ 5 │┃ 6 ┃┃ 7 ┃┃ 8 ┃│ 9 ││10 │
└───┘└───┘└───┘└───┘└───┘┗━━━┛┗━━━┛┗━━━┛└───┘└───┘
──────────▶
take: 3
cursor: 5
skip: 2
│
│
│
▼
┌───┐┌───┐┌───┐┌───┐┌───┐┌───┐┏━━━┓┏━━━┓┏━━━┓┌───┐
│ 1 ││ 2 ││ 3 ││ 4 ││ 5 ││ 6 │┃ 7 ┃┃ 8 ┃┃ 9 ┃│10 │
└───┘└───┘└───┘└───┘└───┘└───┘┗━━━┛┗━━━┛┗━━━┛└───┘
──────────▶
take: 3
The Query Engine now automatically restarts with an exponential backoff with jitter, if it exits for some reason, for example in the case of a panic. That helps a lot to make Prisma Client more resilient in production! https://github.com/prisma/prisma/issues/2100
@default(cuid / uuid)If you introspect a Prisma 1 schema, the introspection now correctly recognizes cuid or uuid usage
https://github.com/prisma/prisma/issues/2499
prismagenerate does not work in folders with spacesfindMany with a select argument errors out with models with self-relations (sometimes)selected in queriesfindMany fails to select an enum list & a relation scalar at the same timeprisma-client-jsvscode@default() puts curcor after ) instead of inside ()@unique @uniqueprisma-enginesHuge thanks to @Sytten, @thankwsx, @zachasme for helping!
Today, we are issuing the sixth Beta release: 2.0.0-beta.6 (short: beta.6).
raw queries with Prisma ClientThanks to @zachasme and @Sytten, the prisma.raw command became more powerful in https://github.com/prisma/prisma/pull/2311. There are two changes we introduce for raw:
sql-template-tag helpersPrisma Client's raw mode utilizes the sql-template-tag library. In order to construct raw SQL queries programmatically, Prisma Client now exposes a few helper functions:
import { sql, empty, join, raw, PrismaClient } from '@prisma/client'
const prisma = new PrismaClient()
const rawQueryTemplateFromSqlTemplate = await prisma.raw(
sql`
SELECT ${join([raw('email'), raw('id'), raw('name')])}
FROM ${raw('User')}
${sql`WHERE name = ${'Alice'}`}
${empty}
`
)
Sometimes, a static template string is not enough. Then constructing a string dynamically is the right choice. For this situation, we added support for arbitrary positional parameters:
const result = await prisma.raw(
'SELECT * FROM User WHERE id = $1 OR email = $2;',
1,
'[email protected]'
)
?pgbouncer=true parameter (forceTransactions from the PrismaClient is now deprecated and will be removed in an upcoming release)prisma formatprismaintrospect success message&sslcert=server-ca.pem in PostgreSQL connection url throw Error opening a TLS connection: One or more parameters passed to a function were not valid.prisma format will move it out of the modelPrisma Client does not workprisma-client-jsforceTransactions / pgBouncervscodeprisma-enginesHuge thanks to @Sytten, @thankwsx, @zachasme for helping!
Today, we are issuing the fifth Beta release: 2.0.0-beta.5 (short: beta.5).
From now on, you don't need to build your own binaries for Alpine Linux and all musl-based distros anymore. They're shipped by default with the Prisma CLI and Prisma Client.
The new Node v14 is from now on fully supported with the Prisma CLI and Prisma Client.
You can now use the new Json type that was introduced in the last release also in Prisma Client.
prismaprisma-client-jsmigratevscodeprisma-enginesHuge thanks to @Sytten for helping!
Today, we are issuing the fourth Beta release: 2.0.0-beta.4 (short: beta.4).
Prisma now supports working with JSON data with the new Json type in the Prisma data model.
Here's an overview of how it works with different Prisma tools/workflows:
The prisma introspect command maps the following column types to Json:
JSON and JSONBJSONprisma migrate uses the following data type when creating a column for a field of type Json:
JSONBJSONFields of type Json will be exposed as plain JavaScript objects in the Prisma Client API.
prisma formatFrom now on, you can run prisma format in your project, to make your schema.prisma pretty without the VSCode extension 💅
Prisma now supports Yarn workspaces 🎉
.prisma folderThe generation of Prisma Client into node_modules sometimes caused problems with package managers (e.g. Yarn) which would occasionally delete the generated code.
In order to make the generation more robust, Prisma Client is now generated into a folder called node_modules/.prisma. Because of the leading dot in the folder name, package managers do not touch the folder any more. This results in the following folder structure:
node_modules/
↪ .prisma
↪ client
↪ schema.prisma
↪ index.js
↪ index.d.ts
↪ query-engine-darwin
↪ @prisma/client (imports the generated code from `.prisma`)
Note that the generated Prisma Client code in .prisma is now imported into @prisma/client which means there is no change for how you import and use Prisma Client in your code! You can still import Prisma Client as before with:
import { PrismaClient } from '@prisma/client'
The prisma studio --experimental command now accepts a --browser option to let you choose your preferred browser for Prisma Studio, e.g.:
prisma studio --browser "Google Chrome" --experimental
Here's an overview of the browser names you can use per platform (note that double quotes are required when the browser name contains space and the right capitalization is required too):
| OS | Browser | Argument for --browser |
|---|---|---|
| Mac OS | Chrome | "Google Chrome" |
| Firefox | "Firefox" |
|
| Firefox (Developer) | "Firefox Developer Edition" |
|
| Safari | "Safari" |
|
| Windows | Chrome | "Google Chrome" |
| Firefox | "Firefox" |
|
| Firefox (Developer) | "Firefox Developer Edition" |
|
| Brave | "Brave" |
|
| Linux | Chrome | "google-chrome" |
| Firefox | "firefox" |
|
| Firefox (Developer) | "firefox-developer-edition" |
|
| Brave | "brave" |
prismaRUST_BACKTRACE=full for a verbose backtrace.introspect fails on SQLiteprisma-client-jsnull for a nullable relation results in errornullmigratevscodealpha version of extensionHuge thanks to @Sytten for helping!
Today, we are issuing the third Beta release: 2.0.0-beta.3 (short: beta.3).
prisma2 command is now deprecated in favor of prismaprismareferences must refer to a unique criteria in the related model pages_language. But it is referencing the following fields that are not a unique criteria: page_id"MA==@relation annotation's field attribute should not be able to accept scalar listsprisma introspect --print?prisma2 executablegenerate does not work in folders with spacesprisma-client-jsmigrate--preview is ignored when doing prisma migrate down --preview --experimentalvscodeToday, we are issuing the second Beta release: 2.0.0-beta.2 (short: beta.2).
We want to give a huge shoutout to @Sytten who helped us fix some issues in the Rust codebase 🎊
count queries in Prisma ClientIn previous versions of Prisma Client, it was not possible to provide any filter arguments when using .count. With this release, you can provide the same filter arguments from findMany:
const numberOfUsersCalledBob = await prisma.user.count({ where: { name: 'Bob' }})
With this release, we were able to fix a lot of nasty bugs like some schema validation issues in VS Code (#1989 and #1970) as well as a Prisma Migrate bug with 1-n self-relations.
prisma.env file is used - Closes #1155version commandprisma2 generate --watch exits when no models are defined in schema.prismaTeams uses the scalar fields tmID. The arity of those fields must be the same. The relation field is required but the scalar fields are optional.prisma2 generate --watch exits when no models are defined in schema.prisma.env file is usedprisma-client-jscreateprisma-enginesmigrateWe are extremely excited to launch the first official Beta of Prisma 2.0 today! 🎉 Along with this release, we have also published a new website and an updated Prisma 2.0 documentation. This makes Prisma 2.0 the default for developers who are getting started with Prisma.
If you have been using Prisma Migrate before to create your models and their relations, the new relation syntax can seem a bit counterintuitive at first. Here's a quick overview of the most important things to consider when upgrading.
Note that this only covers one-to-one and one-to-many relations. Prisma's implicit many-to-many relations are adjusted by manually adding the @relation attribute with a single field reference to both sides of the relation (most often this looks as follows: @relation(references: [id])).
Consider this sample schema from preview025:
model User {
id Int @id @default(autoincrement())
profile Profile?
posts Post[]
}
model Profile {
id Int @id @default(autoincrement())
user User // backed up by a foreign key called `user` in the DB
}
model Post {
id Int @id @default(autoincrement())
author User // backed up by a foreign key called `author` in the DB
}
<details><summary>Expand for the corresponding SQL</summary>
CREATE TABLE "User" (
id integer PRIMARY KEY,
name text NOT NULL DEFAULT ''::text
);
CREATE TABLE "Profile" (
bio text NOT NULL DEFAULT ''::text,
id integer PRIMARY KEY,
user integer NOT NULL,
FOREIGN KEY ("user") REFERENCES "User"(id)
);
CREATE TABLE "Post" (
id integer PRIMARY KEY,
title text NOT NULL
author integer NOT NULL,
FOREIGN KEY ("author") REFERENCES "User"(id)
);
</details>
Note that in this case, the foreign keys in the underlying database are located on the Profile and Post tables. The User table does not have any foreign keys (which means the profile and posts relation fields on the User model are virtually maintained by Prisma).
The new syntax requires you to make the foreign key explicit in the Prisma schema (so you need to add another field in addition to the already existing relation field). This new field is your relation scalar field and directly represents the foreign key in the underlying database.
Assume you're now upgrading to 2.0.0-beta.1:
npm install @prisma/[email protected]
npm install @prisma/[email protected] --save-dev
Without touching the database, one way to adjust your Prisma schema to adhere to the new syntax would be as follows:
model User {
id Int @id @default(autoincrement())
profile Profile?
}
model Profile {
id Int @id @default(autoincrement())
user User @relation(fields: [userId], references: [id])
+ userId Int @map("user") // relation scalar field (used in the `@relation` attribute above)
}
model Post {
id Int @id @default(autoincrement())
author User @relation(fields: [authorId], references: [id])
+ authorId Int @map("author") // relation scalar field (used in the `@relation` attribute above)
}
In this code, you introduced the userId and authorId fields on Profile and Post. These fields are your relation scalar fields and represent the foreign key in your database. But because the current foreign keys in the database are called user and author and therefore don't map directly to the model fields, you need to annotate the fields with @map to "map" them to a differently named database column.
You can then re-generate Prisma Client. Note that the prisma2 command has been renamed to prisma in 2.0.0-beta.1, so you need to invoke the generate command as follows:
npx prisma generate
Note that the new relation scalar field is currently read-only in the generated Prisma Client API. To modify the connections in youe database, you can keep using Prisma Client's nested write queries.
With this release the Preview period for Prisma 2.0 ends. This means that releases will not be tagged preview any more, but with beta. Today's release is called: 2.0.0-beta.1.
Since its initial release, the main repository for Prisma 2.0 has been called prisma2.
Because Prisma 2.0 is now the default for developers getting started with Prisma, the Prisma repositories have been renamed as follows:
prisma/prisma2 repository has been renamed to prisma/prismaprisma/prisma repository has been renamed to prisma/prisma1prisma2 CLIDuring the Preview period, the CLI for Prisma 2.0 was invoked using the prisma2 command. With Prisma 2.0 being the default for new developers getting started with Prisma, the command is changed to just prisma. The exising prisma command of Prisma 1 is renamed to prisma1.
Also note that the installation of the npm packages changes:
| Prisma version | Old CLI command | New CLI command | Old npm package name | New npm package name |
|---|---|---|---|---|
| 2.0 | prisma2 |
prisma |
prisma2 |
@prisma/cli |
| 1.X | prisma |
prisma1 |
prisma |
prisma1 |
The Beta release introduces a new relation syntax which makes the @relation attribute required in each relation in the Prisma schema. Note that it often is enough to only declare the attribute only on the side of the relation (the side that stores the foreign key in the underlying database).
Additionally, for one-to-one and one-to-many relations, you need add a relation scalar field to the model which is used in the @relation attribute. This relation scalar field directly maps to the foreign key in the underlying database. Note that the foreign key is read-only in the Prisma Client API, to modify a relation you can keep using nested write queries as before.
Here's an overview for how relations need to be updated.
During the Preview period, a 1-1-relation could be defined as follows:
model User {
id Int @id @default(autoincrement())
profile Profile
}
model Profile {
id Int @id @default(autoincrement())
user User
}
With the new Beta, you now must determine which side should store the foreign key. You can do so by adding the @relation attribute with its corresponding relation scalar field to the model:
model User {
id Int @id @default(autoincrement())
profile Profile
}
model Profile {
id Int @id @default(autoincrement())
+ user User @relation(fields: [userId], references: [id])
+ userId Int // relation scalar field (used in the `@relation` attribute above)
}
This Prisma schema is represented as follows in SQL (the foreign key is stored on Profile):
CREATE TABLE "User" (
id SERIAL PRIMARY KEY
);
CREATE TABLE "Profile" (
id SERIAL PRIMARY KEY,
"userId" INTEGER NOT NULL UNIQUE,
FOREIGN KEY ("userId") REFERENCES "User"(id)
);
During the Preview period, a 1-n-relation could be defined as follows:
model User {
id Int @id @default(autoincrement())
posts Post[]
}
model Post {
id Int @id @default(autoincrement())
author User
}
With the new Beta, you now must add the @relation attribute and its corresponding relation scalar field to the non-list field of the relation:
model User {
id Int @id @default(autoincrement())
posts Post[]
}
model Post {
id Int @id @default(autoincrement())
+ author User @relation(fields: [authorId], references: [id])
+ authorId Int
}
This Prisma schema is represented as follows in SQL:
CREATE TABLE "User" (
id SERIAL PRIMARY KEY
);
CREATE TABLE "Post" (
id SERIAL PRIMARY KEY,
"authorId" integer NOT NULL,
FOREIGN KEY ("authorId") REFERENCES "User"(id)
);
During the Preview period, a m-n-relation could be defined as follows:
model Post {
id Int @id @default(autoincrement())
categories Category[]
}
model Category {
id Int @id @default(autoincrement())
posts Post[]
}
With the new Beta, you now must add the @relation attribute to both sides of the relation:
model Post {
id Int @id @default(autoincrement())
+ categories Category[] @relation(references: [id])
}
model Category {
id Int @id @default(autoincrement())
+ posts Post[] @relation(references: [id])
}
Prisma will maintain the relation with the following relation table:
CREATE TABLE "Category" (
id SERIAL PRIMARY KEY
);
CREATE TABLE "Post" (
id SERIAL PRIMARY KEY
);
-- Relation table + indexes -------------------------------------------------------
CREATE TABLE "_CategoryToPost" (
"A" integer NOT NULL REFERENCES "Category"(id),
"B" integer NOT NULL REFERENCES "Post"(id)
);
CREATE UNIQUE INDEX "_CategoryToPost_AB_unique" ON "_CategoryToPost"("A" int4_ops,"B" int4_ops);
CREATE INDEX "_CategoryToPost_B_index" ON "_CategoryToPost"("B" int4_ops);
The changes in the relation syntax were needed to enable more complex relation configurations, e.g. when using multi-field IDs.
Note that we aim to simplify the current syntax in the future again ("take one step backward, to be able to move two steps forward").
prisma2 npm package is deprecatedThe prisma2 npm package is now deprecated, the Prisma 2.0 CLI can now be installed via the @prisma/cli npm package, e.g.:
npm @prisma/cli --save-dev
npx prisma
To prevent confusions during installation, it now outputs the following when you try to install it:
┌─────────────────────────────────────────────────────────────┐
│ │
│ The package prisma2 has been renamed to @prisma/cli. │
│ │
│ Please uninstall prisma2 from your project or globally. │
│ Then install @prisma/cli to continue using Prisma 2.0: │
│ │
│ # Uninstall old CLI │
│ npm uninstall prisma2 │
│ │
│ # Install new CLI │
│ npm install @prisma/cli --save-dev │
│ │
│ # Invoke via npx │
│ npx prisma --help │
│ │
│ Learn more here: https://pris.ly/preview025 │
│ │
└─────────────────────────────────────────────────────────────┘
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version