-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Description
Bug: Prisma 7.x WASM DMMF generation fails with "Cannot create a string longer than 0x1fffffe8 characters"
Environment
- Prisma Version: 7.1.0 (prisma-client-js, @prisma/adapter-pg)
- Node.js: v22.x
- OS: Linux (WSL2)
- Database: PostgreSQL 16
Description
When running npx prisma generate on a large Prisma schema (~110,000+ lines, 1,668+ models), the generation fails with a V8 string limit error. The WASM-based DMMF (Data Model Meta Format) generator cannot handle schemas that produce JSON output exceeding ~512MB.
Error Message
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
or
RangeError: Cannot create a string longer than 0x1fffffe8 characters at Object.stringify ()
Steps to Reproduce
- Create a Prisma schema with 1700+ models
- Run
npx prisma generate - Observe OOM or string limit error
Schema Size Observations
| Schema Lines | Models | Enums | Result |
|---|---|---|---|
| ~108,315 | ~1,632 | ~1,058 | ✅ Works (32.89s) |
| ~110,558 | ~1,668 | ~1,094 | ❌ Fails |
The difference of ~2,233 lines (~36 models) crosses the threshold.
Workaround
Temporarily comment out less-critical models to reduce schema size below the limit.
Expected Behavior
Prisma should either:
- Stream DMMF generation instead of building a single string
- Provide a native (non-WASM) generator option for large schemas
- Support schema splitting across multiple files with proper cross-file relations
- Document the schema size limit clearly
Additional Context
- Multi-file schema support (prisma/schema/*.prisma) does NOT help - the DMMF is still generated as a single output
- engineType = "binary" in generator config does NOT help - the DMMF generation still uses WASM
- Increasing Node.js heap (NODE_OPTIONS=--max-old-space-size=8192) does NOT help - this is a V8 hard limit on string size
Impact
This blocks enterprise applications with complex data models from using Prisma 7.x without fragmenting their schema or removing models.
Fix Submitted — Two Alternative Approaches
Four PRs have been submitted implementing two different approaches. The Prisma team can choose either or combine both.
Approach 1: WASM Buffered (no new binary required)
| PR | Repo | Description |
|---|---|---|
| prisma-engines#5757 | prisma-engines | Adds chunked Uint8Array buffer reads from WASM memory via get_dmmf_bytes() |
| prisma#29137 | prisma | TypeScript fallback: detects V8 RangeError, reads WASM buffer in chunks, stream-parses with @streamparser/json |
Approach 2: Binary Streaming (no memory ceiling)
| PR | Repo | Description |
|---|---|---|
| prisma-engines#5761 | prisma-engines | Adds get-dmmf subcommand to prisma-fmt using serde_json::to_writer() for zero-copy streaming |
| prisma#29149 | prisma | TypeScript fallback: spawns prisma-fmt get-dmmf, stream-parses stdout via @streamparser/json |
Comparison
| Aspect | WASM Buffered | Binary Streaming |
|---|---|---|
| Memory ceiling | ~1.5-2GB (WASM32 limit) | Unlimited |
| Peak memory | 2x DMMF size | 1x (streaming) |
| New binary required | No | Yes (prisma-fmt) |
| Works today | Yes (WASM-only path) | Needs binary distribution |
| Rust complexity | Medium (Mutex + chunks) | Low (to_writer + CLI) |