Today, we are excited to share the 5.1.0
stable release 🎉
🌟 Help us spread the word about Prisma by starring the repo ☝️ or tweeting about the release.
Highlights
After two big releases where we released Client extensions for production usage (4.16.0
) and made Prisma faster by default (5.0.0
), we have focused on some smaller issues to make the experience with these new features even better.
Community contributions
Our community has been on the roll! We appreciate everyone who helps us by opening a GitHub issue or proposing a fix via Pull Requests. In this release, we're excited to highlight multiple community contributions:
Better performance: Fewer SQL queries on PostgreSQL & CockroachDB
In our continued and ongoing work to make Prisma faster, we identified some Prisma Client queries that led to multiple SQL statements being executed — although in specific databases, that was not necessary.
Hence we optimized our internal SQL generation for PostgreSQL and CockroachDB to generate more efficient SQL queries:
Simple create
query
In a simple create
query, RETURNING
makes the second query and the transaction statements obsolete:
Prisma Client query
prisma.user.create({
data: { name: "Original name" }
})
Before v5.1.0
BEGIN
INSERT INTO "User" ("name") VALUES ($1) RETURNING "User"."id"
SELECT "User"."id", "User"."name" FROM "User" WHERE "User"."id" = $1;
COMMIT
5.1.0 and later
-- Sends 1 statement (instead of 2) and omits the transaction
INSERT INTO "User" ("name") VALUES ($1) RETURNING "User"."id", "User"."name"
Simple update
query
For a simple update
query, RETURNING
makes both additional queries and the transaction statements obsolete:
Prisma Client query
prisma.user.update({
where: { id: 1 },
data: { name: "updated" }
})
Before v5.1.0
BEGIN
SELECT id FROM "User" WHERE "User".id = 1;
UPDATE "User" SET name = 'updated' WHERE "User".id = 1;
SELECT id, name FROM "User" WHERE "User".id = 1;
COMMIT
5.1.0 and later
-- Sends 1 statement (instead of 3) and omits the transaction
UPDATE "User" SET name = 'updated' WHERE "User".id = 1 RETURNING "User".id, "User".name;
Simple update
query, return with relation value
One SELECT
query could easily be dropped in a simple update
query that should return a relation value as well:
Prisma Client query
prisma.user.update({
where: { id: 1 },
data: { name: "updated" },
includes: { posts: true }
})
Before v5.1.0
BEGIN
SELECT id FROM "User" WHERE "User".id = 1;
UPDATE "User" SET name = 'updated' WHERE "User".id = 1;
SELECT id, name FROM "User" WHERE "User".id = 1;
SELECT id, title FROM "Post" WHERE "Post"."userId" = 1;
COMMIT
5.1.0 and later
-- Sends 3 statements (instead of 4)
BEGIN
UPDATE "User" SET name = 'updated' WHERE "User".id = 1 RETURNING "User".id;
SELECT id, name FROM "User" WHERE "User".id = 1;
SELECT id, title FROM "Post" WHERE "Post"."userId" = 1;
COMMIT
Empty update
query
An empty update
query can be optimized to skip the transaction and the second identical query by creating specific handling for this edge case in our code:
Prisma Client query
prisma.user.update({
where: { id: 1 },
data: {},
})
Before v5.1.0
BEGIN
SELECT id, name FROM "User" WHERE "User".id = 1;
SELECT id, name FROM "User" WHERE "User".id = 1;
COMMIT
5.1.0 and later
-- Sends 1 statement (instead of 2) and omits the transaction
SELECT id, name FROM "User" WHERE "User".id = 1;
Simple + relation update
query (but do not return relation value)
An update of both the model and its relation, we could drop 2 SELECT
queries that we did before without ever using their return values:
Prisma Client query
prisma.user.update({
where: { id: 1 },
data: {
name: "updated",
posts: {
update: {
where: { id: 1 },
data: {
title: "updated"
}
}
}
}
})
Before v5.1.0
BEGIN
SELECT id, name FROM "User" WHERE "User".id = 1;
UPDATE "User" SET name = 'updated' WHERE "User".id = 1 RETURNING "User".id;
SELECT "id", "postId" FROM "Post" WHERE "Post".id = 1;
UPDATE "Post" SET title = 'updated' WHERE "Post"."userId" = 1 AND "Post".id = 1;
SELECT id, name FROM "User" WHERE "User".id = 1;
COMMIT
5.1.0 and later
-- Sends 3 statements (instead of 5)
BEGIN
UPDATE "User" SET name = 'updated' WHERE "User".id = 1 RETURNING "User".id, "User".name;
SELECT "id", "postId" FROM "Post" WHERE "Post".id = 1;
UPDATE "Post" SET title = 'updated' WHERE "Post"."userId" = 1 AND "Post".id = 1;
COMMIT
In the next releases, we will continue optimizing Prisma Client queries to only run the minimal amount of SQL queries necessary.
If you notice any Prisma Client queries that are affected right now, please check the issues under our performance/queries
label. If you didn’t find one for what you’re seeing, please create a new issue. This will be super useful for us to understand all (edge) cases. Thank you!
Prisma Studio now supports directUrl
Our CLI command prisma studio
that opens Prisma Studio now also can use the directUrl
property of the datasource
block so you can make it talk to a different database than defined in url
. This makes it easier to use Studio alongside the Prisma Data Proxy and Accelerate.
Prisma Client: No more type clashes
We fixed (almost) all cases where using a specific term as a model name in your Prisma Schema would lead to a type clash due to Prisma’s generated typings. As a result of a type clash, it was not possible to use that model in your code (this was e.g. the case if you named a model Model
or ModelUpdate
).
We also deprecated the <ModelName>Args
type as part of that fix. Going forward, <ModelName>DefaultArgs
should be used instead.
Fixes and improvements
Prisma Client
Prisma Studio
Language tools (e.g. VS Code)
Credits
Huge thanks to @skyzh, @alula, @michaelpoellath, @RobertCraigie, @Gerschtli, @andyjy, @mejiaej, @iurylippo, @mrazauskas for helping!