Prisma's biggest strength is how readable its schema file is, but that readability can sometimes hide real complexity in your database design. I fell into this trap a few times while modeling product, category, variant, and stock relationships on BalkoLüx.
Adding product variants (color, size) as a JSON field on the product model felt faster at first; but as stock levels grew, variant-based filtering and reporting queries that had to search inside JSON degraded quickly. The fix was breaking ProductVariant out into its own table with its own stock row per variant combination; query complexity went up, but it became indexable and scalable.
The N+1 query problem can sneak in with Prisma even when using include, especially with nested includes. Selecting only the fields you actually need with select, and switching to cursor-based pagination instead of take/skip on findMany where appropriate, noticeably cut query times on large product listings.
Migration discipline is also not something to take lightly: I test every migration headed to production for reversibility on an empty staging database first. After living through how adding a foreign key constraint in the wrong order can cause a live outage, I never skip that step again.
Despite all the convenience an ORM provides, schema design is still a discipline built on relational database fundamentals.
{ }