If you have been using Prisma and you keep wondering "wait, what is Prisma Client actually?" and "why do I have to run prisma generate every five minutes?", this post is for you. We are going to use one simple analogy that makes the whole thing click. Promise.

The kitchen and the menu

Imagine you walk into a restaurant.

There is a kitchen in the back. The kitchen is where the food actually lives. You cannot just walk in there and grab something. You have to ask for it.

There is a recipe book in the kitchen that the chef writes. It says exactly what dishes exist, what is in them, and how they are made. The recipe book is the source of truth. If a dish is not in the recipe book, it does not exist.

And there is a menu sitting on your table. The menu is what you read. You point at things on the menu and the kitchen brings them to you. You never see the recipe book. You never go in the kitchen. You just read the menu and order.

Got that picture? Good. Now we can map this to Prisma.

So what is Prisma Client?

Prisma Client is the menu.

It is a piece of code that your app reads to figure out what it can ask the database for. It has one button (a method) for each model. So if your schema has User, the menu has prisma.user.findMany(), prisma.user.create(), prisma.user.delete(), and so on. If your schema has Post, you also get prisma.post.findMany(). The menu is shaped exactly to your schema.

That is why Prisma feels magical with autocomplete. Your editor sees the menu, knows exactly what every dish takes (the right fields, the right types), and stops you from ordering "a pizza with banana" when the recipe book says pizza only has cheese and tomato.

And what does prisma generate do?

Here is the key insight.

The menu is not handwritten by humans. It is printed.

When the chef writes or updates the recipe book, somebody has to walk over to the printer, hit print, and bring out a fresh menu. Until that happens, the menu on your table still shows yesterday's dishes.

In Prisma, that printer is the command:

npx prisma generate

It reads your schema (the recipe book) and prints a fresh Prisma Client (the menu). The result is written to a folder, in your project that folder is generated/prisma/.

So:

The schema is the recipe book.
The database is the kitchen.
Prisma Client is the menu.
prisma generate is the act of printing a new menu.

Why do I have to run it every time the schema changes?

Because the menu does not auto update. It is a printed thing.

Picture this:

1. You add a nationality field to User in the schema.
2. The chef updated the recipe book.
3. But the menu still says "User has name and email only".
4. Your code tries to write prisma.user.create({ data: { name: "Bob", nationality: "FR" } }).
5. The menu does not know what nationality is. TypeScript yells at you.
6. You run prisma generate. A new menu is printed.
7. Now the menu has nationality. TypeScript is happy. Your code works.

That little dance is the whole reason prisma generate exists. The menu has to be reprinted whenever the recipe book changes.

"Wait, but prisma migrate dev worked fine without me running generate"

Yes. Some commands secretly press the print button for you.

• prisma migrate dev -> changes the database and reprints the menu.
• prisma migrate reset -> wipes the database and reprints the menu.
• npm install -> reprints the menu (Prisma has a postinstall step).

You only need to run prisma generate by hand when none of those happened. For example:

• You used prisma db push instead of migrate dev.
• You edited the schema and you only want a fresh menu without touching the database.
• You changed where the menu gets printed (the output setting in your schema).
• A teammate pushed schema changes and you pulled them, but you had not yet reinstalled deps.

Why is the menu separate from the kitchen?

Good question. You might be thinking, "if the chef can update the recipe book, why doesn't my code just read it directly?"

Two reasons.

Speed. Reading SQL on every call would be slow. The menu is pre printed once, then your code uses it thousands of times. Reading a menu is faster than yelling into the kitchen every time.

Type safety. TypeScript needs to know the shape of your data before the code runs. The menu gives it that shape ahead of time. The database itself does not speak TypeScript.

So Prisma takes a snapshot of your schema, turns it into typed JavaScript that your editor and TypeScript can understand, and your app uses that snapshot at runtime. The trade off is that the snapshot can go stale, which is why you regenerate it.

The full picture in one image

[ schema.prisma ]            <-- you write this
       |
       |  prisma migrate dev   ----> [ database ]      (the kitchen)
       |
       |  prisma generate      ----> [ Prisma Client ] (the menu)
                                          |
                                  your code imports
                                  and uses this every day

Whenever you change the schema, both arrows need to fire again. One updates the kitchen. One reprints the menu. migrate dev happens to fire both for you, which is why most beginners do not see generate directly until they hit a weird type error.

Mental model in two sentences

Prisma Client is a custom menu, printed from your schema, that your code reads to order things from the database.

prisma generate is the print button, and you have to press it every time the schema changes, unless another command quietly presses it for you.

That is the entire idea. Once the menu and recipe book picture is in your head, the rest of Prisma stops feeling like magic and starts feeling like furniture you can move around with confidence.

A tiny exercise

Try this when you have a minute:

1. Open generated/prisma/client.ts in your project.
2. Search for one of your model names, like User.
3. Notice all the methods and types that already have your model's shape baked in.

That whole file did not exist before you ran prisma generate. Prisma wrote it for you. That is the menu, and now you know exactly what it is.