Bump the prisma group with 4 updates

[dependabot]

Updates the requirements on @prisma/adapter-pg, @prisma/client, @prisma/internals and prisma to permit the latest version.
Updates @prisma/adapter-pg to 7.4.0

Release notes

Sourced from @​prisma/adapter-pg's releases.

7.4.0

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"
</tr></table> 

... (truncated)

Commits

• See full diff in compare view

Updates @prisma/client to 7.4.0

Release notes

Sourced from @​prisma/client's releases.

7.4.0

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"
</tr></table> 

... (truncated)

Commits

• 7060f68 chore(deps): update engines to 7.4.0-20.ab56fe763f921d033a6c195e7ddeb3e255bdb...
• 91a24a9 feat: query plan caching (#29038)
• b49d446 chore(deps): update engines to 7.4.0-18.2997580c8cb38878f73e100453e7b27119e8f...
• 3c99935 chore(deps): update engines to 7.4.0-17.57b675f79cd26fbf702d70f9a13d2b7b2fad9...
• e7504d7 chore(deps): update engines to 7.4.0-16.d0314091cdd30494eefc61d346f8c09aca20d...
• 1e6c91c chore(deps): update engines to 7.4.0-15.6129681d45ea4510d3372dd5b28f6b8927584...
• e1bfd22 chore(deps): update engines to 7.4.0-13.e876f7aec6b9be3e5147d061ed521ec45a845...
• 12ca969 chore(deps): update engines to 7.4.0-12.aa5ee090ba89988f1dce71be263f4bcd9519b...
• 36b57cb chore(deps): update engines to 7.4.0-11.8583547702bad6d8e7de7d9812f7ec5c22e1c...
• b6afc3f test: initialize the test client before the QPE (#29130)
• Additional commits viewable in compare view

Updates @prisma/internals to 7.4.0

Release notes

Sourced from @​prisma/internals's releases.

7.4.0

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"
</tr></table> 

... (truncated)

Commits

• 7060f68 chore(deps): update engines to 7.4.0-20.ab56fe763f921d033a6c195e7ddeb3e255bdb...
• b49d446 chore(deps): update engines to 7.4.0-18.2997580c8cb38878f73e100453e7b27119e8f...
• 3c99935 chore(deps): update engines to 7.4.0-17.57b675f79cd26fbf702d70f9a13d2b7b2fad9...
• e7504d7 chore(deps): update engines to 7.4.0-16.d0314091cdd30494eefc61d346f8c09aca20d...
• 1e6c91c chore(deps): update engines to 7.4.0-15.6129681d45ea4510d3372dd5b28f6b8927584...
• e1bfd22 chore(deps): update engines to 7.4.0-13.e876f7aec6b9be3e5147d061ed521ec45a845...
• 12ca969 chore(deps): update engines to 7.4.0-12.aa5ee090ba89988f1dce71be263f4bcd9519b...
• 36b57cb chore(deps): update engines to 7.4.0-11.8583547702bad6d8e7de7d9812f7ec5c22e1c...
• 2b34d12 chore(deps): update engines to 7.4.0-8.534ac5c12b9088d160899554cc8c11039ffb97...
• 14a5fed chore(deps): update engines to 7.4.0-7.a09903a14c97c90b4fa191ca42b02ec9a78094...
• Additional commits viewable in compare view

Updates prisma to 7.4.0

Release notes

Sourced from prisma's releases.

7.4.0

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"
</tr></table> 

... (truncated)

Commits

• 1df1c6d fix(cli-generator): outdated default generator provider (#29089)
• 710c25d fix: update dependencies to fix pnpm audit (#29128)
• fdabc1c fix(cli): remove Prisma Pulse from CLI help message (#29093)
• 1677a32 docs: fix broken getting started links across repository (#28948)
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[samchon]

@dependabot merge

[dependabot]

Beginning January 27, 2026, Dependabot will no longer support the @dependabot merge command. Please use GitHub's native pull request controls instead. Please see the changelog announcement for additional details.