TypeScript: update/create/upsert `data` typing causes extreme TSC memory/time on large schemas

[tonxxd]

Summary

On a schema with on the order of 30+ models and rich relations, a normal pattern—HTTP body validated at runtime (e.g. Zod / OpenAPI), then passed into db.<model>.update({ data: … })—can push tsc over a 4 GB Node heap. The same project compiles if the heap is raised (e.g. 8 GB) or if the payload is forced through any before it reaches data.

This is a type-checker cost issue, not a runtime bug.

Environment

• @zenstackhq/orm: 3.5.x (same general behavior on recent 3.x)
• TypeScript: 5.9.x
• tsc full project check/emit including generated zenstack/*.ts and declaration: true (emit makes it worse, but OOM reproduces on full check/emit)

What we see with --generateTrace + @typescript/analyze-trace

Hot spots cluster on Compare types / Determine variance while checking an update call. The stack points at instantiated types from:

• UpdateInput / NestedUpdateInput (recursive relation update shapes)
• @zenstackhq/schema helpers such as GetModelField, FieldIsArray, etc.

Relevant ORM sources on dev:

• UpdateArgs / UpdateInput / NestedUpdateInput — see especially NestedUpdateInput, which ties data: UpdateInput<...> back into the same recursive structure.
• update on the client contract (SelectSubset)

Minimal pattern that hurts (representative)

After OpenAPI/Zod validation, we want to forward the body into ZenStack:

import type { AgentUpdateArgs } from "#zenstack/input"; // generated

// body: inferred from validator — already validated at runtime
await db.agent.update({
  where: { id },
  data: body as AgentUpdateArgs["data"],
});

Observation: Even when casting to AgentUpdateArgs["data"], TypeScript still ends up doing very heavy work relating that to the update method’s expected argument type (including UpdateInput → NestedUpdateInput → UpdateInput … across the schema graph). On a large schema this can OOM at 4 GB.

Same call with the payload passed as any (or a small helper that returns any) completes quickly and stays under 4 GB—so the issue is structural type comparison / instantiation, not application logic.

Workaround (app side)

We use a tiny helper after runtime validation:

function asZenStackMutateData(data: unknown) {
  return data as any;
}

await db.agent.update({
  where: { id },
  data: asZenStackMutateData(body),
});

This restores 4 GB builds for us but drops static checking on data, which is unfortunate given ZenStack’s otherwise strong typing.

Suggestions

1. Document this as a known TSC limitation for large schemas (similar spirit to Kysely: excessively deep types) and recommend the any / branded escape hatch when data is validated elsewhere.

2. First-party escape type — e.g. a documented type that is intentionally opaque or widened so assignability to UpdateInput does not force full recursive expansion, or a branded unknown that the client API accepts for data / create / update in an overload.

3. Bounded recursion depth for nested relation create/update shapes (optional flag or generic depth parameter), collapsing deeper levels to something like Record<string, unknown>—trading precision for check performance.

4. REST-oriented generated types — optional codegen for scalar-only (or shallow) data types for common CRUD handlers so typical PATCH bodies do not pull full nested relation mutation types.

5. Investigate SelectSubset + update inference — whether the T extends UpdateArgs<...> + SelectSubset<T, …> pair can be specialized for mutations so validated “plain” objects do not trigger worst-case comparison (may relate to past reports such as #610 on the v3 tracker, though that thread mixed Next/incremental factors).

Repro notes for maintainers

• Repro scales with model count and relation graph, not a single minimal file.
• Use tsc --generateTrace traceDir and @typescript/analyze-trace on a private repo or synthetic schema with many models; compare cast to *UpdateArgs['data'] vs data: x as any.
• TypeScript 5.9 vs 5.8 / 6.x may shift timings.

[tonxxd]

Update: mitigation we shipped in our app (pnpm patch)

We implemented direction 1 from the discussion: bounding recursive relation depth in the ORM’s CreateInput / UpdateInput / NestedCreateInput / NestedUpdateInput / NestedUpsertInput / related types (plus threading Depth through ConnectOrCreate* and relation payloads).

Mechanics (conceptually the same as Kysely’s excessively deep types):

• Introduce a small depth counter, e.g. ZenStackDefaultMutationDepth = 3.
• Each time we recurse into nested relation create / update / upsert shapes, use DecMutationDepth<Depth> until Depth extends 0.
• At 0, nested relation mutation payloads widen to Record<string, unknown> instead of fully expanded recursive generics.

Result for us:

• Full tsc -p tsconfig.build.json with NODE_OPTIONS=--max-old-space-size=4096 completes successfully again.
• We could remove app-level as any helpers for mutation data and restore casts to generated *Args["data"] types without blowing the heap.

Implementation note: we ship this as a pnpm patch against published @zenstackhq/orm (dist/index.d.ts + index.d.cts), not from ORM source — a proper upstream PR would ideally implement the same idea in packages/orm source (e.g. crud-types.ts) with tests and docs.

Tradeoff: depth N keeps strong typing for nested writes up to that budget; deeper nesting is intentionally less strict at compile time. Default 0 is a bad default (would interact badly with DecMutationDepth / never and collapse typing too early). We use 3 as a reasonable default.

If this direction is acceptable for ZenStack, we’d be happy to help turn it into a real PR against the repo (source + changelog + documentation on depth vs compile cost).

[ymc9]

Hey @tonxxd , thanks for filing the issue with details and I'm glad to hear you've found a fix that works for you. Yes, a PR is most welcome. I think a depth limit will provide a safety net recursions; however, just feeling 3 will be too conservative. Does a higher limit break immediately for your case?

[tonxxd]

Hey @ymc9 I can definetely run some tests to measure the memory increasy based on the depth, even though i would assume it also depends on my data model which though is not very big. Will update the issue