W
Waspβ€’4w ago
m3dia

Production deployment Issues with large schemas (30+ models)

Hi Wasp team! πŸ‘‹ I'm building a production SaaS on OpenSaaS and hit a critical blocker. My schema has grown to 32 models (733 lines) and wasp build consistently fails with SDK Prisma client generation errors. The issue: SDK generates stub types (20KB) instead of proper Prisma client (2.2MB), causing 88+ TypeScript errors. Key finding: Development works perfectly with a workaround, suggesting it's specifically an SDK generation issue with large schemas. I've submitted a detailed bug report here: https://github.com/wasp-lang/wasp/issues/3303 Critical question: Is 32 models beyond Wasp's intended scale? I'm at a decision point: - Continue with Wasp (if fixable) - Invest 3-4 weeks ejecting to Next.js/Express Any guidance on timeline or whether this is solvable would be hugely appreciated! πŸ™ Context: - Wasp 0.18.0 - Node v24.3.0 - PostgreSQL (Neon) - OpenSaaS template base
GitHub
[BUG] SDK Prisma Client generates with stub types during `wasp buil...
Environment Wasp Version: 0.18.0 Node Version: v24.3.0 Platform: darwin (macOS) Database: PostgreSQL (Neon) Project: OpenSaaS template-based app with 32 custom entities Schema Size: 733 lines, 32 m...
5 Replies
kapa.ai
kapa.aiβ€’4w ago
Hi @m3dia. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- Thank you for your detailed report and for sharing your experience with Wasp at this scale. Based on the knowledge sources provided, there is no explicit documentation or issue that sets a hard limit on the number of models or schema size that Wasp (or its Prisma integration) supports. However, there are several relevant points: - Wasp relies heavily on Prisma for its database layer, and issues with Prisma client generation (especially with large schemas) have been discussed before, though not specifically at your scale. There have been reports of Prisma client generation errors and initialization issues, often related to environment, dependency versions, or project structure, but not directly to schema size limits. For example, issues with Prisma client generation after clean builds or dependency mismatches have been noted, but these were typically resolved by ensuring correct dependency management and running the appropriate commands (e.g., wasp db migrate-dev, prisma generate) at the right times. None of these discussions mention a hard cap on model count or schema lines, but they do highlight that Prisma client generation is a critical and sometimes fragile step in the Wasp build process, especially if the environment is not perfectly aligned or if there are unusual project structures or dependency conflicts [Prisma client initialization error]. - There is an open issue about expanding Prisma support and making Wasp more expressive and robust in handling complex schemas, including support for more advanced Prisma features like enums and types. This suggests that the Wasp team is aware of the need to handle more complex data models and is working towards better support, but there is no explicit mention of current scale limitations [Expand our Prisma support]. - The Wasp team has acknowledged the importance of understanding and supporting production workflows with Prisma, especially as Wasp approaches 1.0. This includes ensuring that the CLI and documentation support typical production use cases, but again, there is no mention of a specific model count or schema size limit [Prisma workflows in production]. - There have been issues with dependency resolution and Prisma version mismatches, especially when there are multiple package.json files or when dependencies are installed at different levels in the project hierarchy. These can cause Prisma to use the wrong version or fail to generate the client properly, which might be exacerbated in larger projects but is not directly tied to schema size [Prisma version issues]. Summary:
There is no evidence in the knowledge sources that 32 models or a 733-line schema is beyond Wasp's intended scale. However, large schemas may expose edge cases or limitations in the current build and dependency management process, especially around Prisma client generation. The fact that development works with a workaround suggests this is not a fundamental architectural limit, but rather a tooling or integration issue. Guidance:
- Since you have already filed a detailed bug report, the best course is to wait for feedback from the Wasp team on that issue. They may be able to provide a fix or workaround, especially if this is a known or newly discovered limitation. - If your timeline is critical and you cannot wait for a fix, you may need to consider your fallback plan. However, based on the knowledge sources, this does not appear to be an intentional or permanent limitation of Wasp, but rather a solvable integration issue. Next Steps:
- Monitor your GitHub issue for updates from the Wasp team. - If you haven't already, ensure your project dependencies are clean and up-to-date, and try running wasp clean followed by wasp build to rule out transient issues. - If you are blocked and need a short-term workaround, consider splitting your schema or reducing complexity temporarily, if possible, until a fix is available. I'm sorry I can't provide a more definitive answer on the timeline, but based on the available information, this should be solvable and is not an intended scale limitation of Wasp. If you need more immediate support, consider reaching out on the Wasp Discord for real-time assistance, as the community and core team are often responsive there. Let me know if you need help with specific error messages or logsβ€”I'm here to help! ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @m3dia, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
genyus
genyusβ€’4w ago
@m3dia I'm curious about your setup. You said you're running Wasp 0.18.0, but you're adding your entities into main.wasp, which hasn't been possible since Wasp 0.14.0. If I try the minimal reproduction from your example on my system running Wasp 0.18.1, I get the following (expected) error:
❌ --- [Error] Your wasp project failed to compile: -------------------------------

- /Users/gary/Dev/test-app/app/main.wasp @ 308:1 - 311:5
Validation error:
Entities can no longer be defined in the .wasp file. You should migrate your entities to the schema.prisma file. Read more: https://wasp.sh/docs/migrate-from-0-13-to-0-14#migrate-to-the-new-schemaprisma-file

307 |
308 | entity CustomModel {=psl
309 | id String @id @default(uuid())
310 | name String
311 | psl=}


❌ --- [Error] Compilation of wasp project failed: --------------------------------

1 errors found
❌ --- [Error] Your wasp project failed to compile: -------------------------------

- /Users/gary/Dev/test-app/app/main.wasp @ 308:1 - 311:5
Validation error:
Entities can no longer be defined in the .wasp file. You should migrate your entities to the schema.prisma file. Read more: https://wasp.sh/docs/migrate-from-0-13-to-0-14#migrate-to-the-new-schemaprisma-file

307 |
308 | entity CustomModel {=psl
309 | id String @id @default(uuid())
310 | name String
311 | psl=}


❌ --- [Error] Compilation of wasp project failed: --------------------------------

1 errors found
I rolled back to 0.13.2 (the last version that supported entities in main.wasp) and your minimal reproduction works fine. What does wasp version output in your environment?
Migration from 0.13.X to 0.14.X | Wasp
This guide only covers the migration from 0.13.X to 0.14.X. If you are migrating from 0.11.X or earlier, please read the migration guide from 0.11.X to 0.12.X first.
Carlos
Carlosβ€’4w ago
Hey @m3dia I was indeed investigating the same thing as @genyus said, reached the same conclusion. I think this might be an issue of an LLM reading from old versions of the docs. The Prisma entities must go in the schema.prisma file.
miho
mihoβ€’4w ago
m3dia
m3diaOPβ€’4w ago
Thanks for all the help and quick replies guys! Its been very useful.

Did you find this page helpful?