A Prisma Schema Change Has Three Lifecycles
One valid PostgreSQL row refused to appear on my Next.js page. The relationship was correct, the SQL join returned the row, and the repository compiled. At runtime, however, Prisma returned an undefined jobOpportunity relation. I had changed the Prisma schema while the development server was running. That change involved three independent lifecycles: prisma migrate updates the database. prisma generate updates the TypeScript client. Restarting Next.js replaces the stale generated client held by
One valid PostgreSQL row refused to appear on my Next.js page.
The relationship was correct, the SQL join returned the row, and the repository compiled. At runtime, however, Prisma returned an undefined jobOpportunity relation.
The stale layer was not the database
I had changed the Prisma schema while the development server was running. That change involved three independent lifecycles:
-
prisma migrateupdates the database. -
prisma generateupdates the TypeScript client. - Restarting Next.js replaces the stale generated client held by the running process.
The first two steps were complete. The third was not.
Coming from PHP and CodeIgniter, this is an important mental-model shift. A request-scoped PHP application normally loads changed code on the next request. A long-running Node.js process can keep generated code and development caches alive.
Prisma provides valuable type safety, but it does not remove complexity—it relocates it.
My new debugging rule is simple:
- Application edit → trust hot reload.
- Prisma model change → migrate, generate, restart.
- Suspicious stale behavior → clear the framework cache and restart.
Before rewriting a correct query, identify which layer is stale.
