Summary

Draft status PR for the engines side of the ongoing Prisma Client performance work. This branch contains query-compiler, query-plan serialization, raw-nested read, and compile-path allocation changes that the sibling Prisma branch consumes.

This is intentionally not merge-ready as a final review unit. The branch is currently large (113 commits ahead, 1 commit behind fresh main) because it accumulated accepted experiments and measurement infrastructure during the performance investigation. I am opening it now so CI and reviewers can see the real state, then the next packaging step should be slicing it into smaller stacked PRs if this is too much to review at once.

Sibling Prisma PR: prisma/prisma#29655

Extracted child PRs:

• perf(quaint): support insert-select CTEs #5821
• perf(query-compiler): reduce parser request allocations #5822

Current split plan: wip/client-performance-pr-stack.md in the sibling Prisma PR branch.

Linked Prisma branch for CI

The engines workflow reads this command from the PR body and builds Prisma adapters/client code from the sibling branch:

/prisma-branch prisma-client-performance-2026-06-08

The reciprocal Prisma PR uses /engine-branch prisma-client-performance-2026-06-08-engines so Prisma CI builds this engines branch.

Main Contents

• Compact and allocation-focused query-plan serialization work.
• Query-compiler graph/translation allocation reductions backed by allocation probes and Criterion checks.
• Raw-nested relation-op emission for pagination/distinct cases, including M:N mapped operation fields and one-to-many parent grouping.
• Raw-nested final-owner schedule marker emission for the Prisma runtime to consume.
• Quaint/Postgres INSERT ... SELECT ... RETURNING and insert-in-CTE prerequisites for a future M:N connect phase-owner, while the direct CTE phase-owner prototype itself stayed reverted.
• Focused benchmark fixtures and allocation-profile infrastructure used by the investigation.

Current Performance Readout

See the sibling Prisma report for the cross-repo rollup: wip/client-performance-intermediate-report.md on prisma-client-performance-2026-06-08.

Important engine-side examples from the journal:

• FK-backed required to-one nested update child-read shortcut: update-set-nested-prisma#27650 full-compile allocations 1621 -> 1453, Criterion about 153.20 -> 135.75 us.
• Raw-nested one-to-many relation-op path: nested-distinct-pagination-query full-compile allocations 726 -> 627, Criterion about 75.20 -> 65.90 us.
• M:N mapped relation-op path: query-m2m-pagination-mapped-distinct full-compile allocations 1519 -> 942, Criterion about 134.37 -> 83.23 us.
• M:N set parent-key delete work: update-m2m-set-empty 1547 -> 1208 and update-m2m-set 1922 -> 1586 full-compile allocations.
• Nested-only upsert shared read: upsert-nested-only-update full-compile allocations 1835 -> 1475, with focused Criterion around 187.37 -> 149.31 us.

Validation Already Run Locally

Representative accepted slices were validated with combinations of:

• cargo check -p query-compiler
• cargo test -p query-compiler --test queries
• focused allocation-profile runs against the named query-compiler fixtures
• focused Criterion patched/control checks for target rows and sampled controls
• make build-qc-wasm for runtime-consuming query-compiler changes

The latest Prisma-side harness restart revalidated the generated prepared-helper slice against this branch context; see the sibling PR for exact pnpm commands.

Proposed Review Split

If this draft PR is too large as expected, split into a stack roughly like:

0. Quaint insert-select / insert-CTE prerequisites for future M:N connect work. Extracted as perf(quaint): support insert-select CTEs #5821.
1. Parser/request allocation reductions. Extracted as perf(query-compiler): reduce parser request allocations #5822.
2. Compact internal plan serialization plus allocation/profile infrastructure.
3. Compiler-local graph/translation allocation reductions.
4. Raw-nested read plans.
5. Write graph pruning.
6. Raw-nested relation ops and final-owner schedule marker emission.

Internal formats in this stack are lockstep-only. There should not be old/new compatibility readers unless a real external persistence boundary is identified.