Designing Production-Grade Models with Prisma (Beyond CRUD)

If you’ve ever looked at your Prisma schema, felt confident , shipped it to production—only to later feel uneasy about relationships, deletes, or edge cases—you’re not alone.

Most Prisma schemas don’t fail because Prisma is bad.
They fail because schemas are treated as table definitions instead of system contracts.

This article is not about Prisma syntax.
It’s about why schemas that “work” often collapse under real business pressure.

The illusions of a “working” schema

A schema feels correct when:

• Migrations run successfully

• CRUD operations work

• No Typescript errors appear

• Page loads and data saves

But production systems don’t break at CRUD.

They break when:

• Two users checkout at the same time

• An admin user deletes data they shouldn’t

• A refund is requested months later

• A use has “multiple active carts”

• Financial data disappears

A schema can be technically valid and logically wrong at the same time.

The most common Prisma smell: nullable everything

If you see this pattern often:

userId String?
orderId String?
productId String?

That’s a red flag.

Nullable foreign keys are usually a symptom of uncertainty:

“I’m not sure if this relationship is always required, so I’ll make it optional.”

Oh, Please! Most relationships in business systems are invariants, not suggestions.

For example:

• An OrderItem without an Order makes no sense

• A Payment without an Order is dangerous

• A CartItem without a Product is invalid

Allowing these states means your database accepts impossible realities, and you know who else accepts impossible realities? Me, every time I estimate a project will take ‘just a few hours’.

Tables are not the problem — missing business rules are

Most developers start modelling like this:

1. Identify entities

2. Create tables

3. Add relations

4. Add indexes

What’s missing is step zero:

Define the business rules first

Examples of real business rules:

• A user can have only one active cart

• An order must always belong to a user

• Payments must never be deleted

• Orders must preserve historical data

• Carts are temporary; orders are permanent

If a rule is real in the business, it should be enforced in the schema—not just in the code.

Why “just handle it in code” is not enough

Relying only on application logic to enforce rules leads to:

• Race conditions

• Duplicate records

• Inconsistent state

• Silent data corruption

Example:
Two requests hit your API at the same time.
Both check: “Does the user already have a cart?”
Both see “no”.
Both create a cart.

Now you have two active carts.

This is not hypothetical it happens.

Databases exist to enforce invariants even when your code misbehaves.

The dangerous misunderstanding of relationships

Many Prisma users struggle with relationships because they as the wrong question:

“How do I connect these models?”

The better question is:

“Who owns this data, and what must never be allowed to happen?”

For example:

• A Cart is mutable and disposable

• An Order is immutable and historical

• A Payment is a financial record

• An OrderItem is a snapshot, not a live product reference

When you don’t answer these questions, relationships become confusing very quickly.

Soft deletes, cascades, and silent data loss

Another common production failure.

Using onDelete: Cascade everywhere without understanding the consequences.

Cascades are database-level hard deletes.

Mixing them without intent can:

• Erase financial history

• Breaks audits

• Violate compliance requirements

If deleting a record would rewrite history, cascading deletes are almost always wrong.

This is one of the most expensive mistakes teams discover too late.

“But my Schema works fine right now”

That’s exactly the danger.

Schemas don’t fail loudly.
They fail quietly, months later, when:

• You need reporting

• You need funds

• You need audit trails

• You need to explain what happened

At that point, fixing the schema means big words like:

• Data migrations

• Backfills

• Downtime

• Lost trust

What this series is about

This series focuses on the parts of schema design that are usually skipped:

• Modeling business rules, not just tables

• Understanding relationship ownership and invariants

• Designing safe deletion strategies

• Preventing silent data corruption before it happens

The goal is not to make Prisma “work”, but to make it correct under pressure.

What’s next

In Part 2, we’ll break down the most misunderstood topic in Prisma schemas:

Understanding Relationships: Ownership, Direction, and Invariants

We’ll cover:

• Why some relationships must never be optional

• How to identify the “owner” of data

• Why some models must be modeled differently

• How to stop guessing when defining relations

Closing thought

A schema that merely stores data is easy to write.
A schema that protects reality takes intent.

This series is about building the second kind.