DEVPREP CODEX · #20

Prisma Interview Questions

Q: What is Prisma and what are its components?

Type-safe ORM for Node/TypeScript: schema.prisma (single source of truth), Prisma Migrate (declarative migrations), Prisma Client (generated typed query builder), Studio (GUI). Replaces hand-written S

Q: What is the N+1 problem in Prisma and how do include/select fix it?

Looping for (const post of posts) post.author issues one query per iteration - the client does NOT auto-batch lazy access. Fix: single findMany({ include: { author: true } }) producing two total queri

Q: What are relation load strategies (joins) in newer Prisma versions?

relationLoadStrategy: "join" (Postgres) emits LEFT JOINs fetching relations in ONE round trip vs classic two-query batch. Choose join for latency-sensitive paths with wide networks; batch (default) of

Q: What is the exact lifecycle of migrations from schema edit to prod, including edge commands?

1. Edit schema → migrate dev --name x diffs against SHADOW db creating migration folder (migrationlock.toml guards provider). 2. Local apply + generate. 3. CI: migrate deploy against ephemeral DB veri

60 curated questions graded from Foundations (Easy) to Practical Patterns (Medium) and Internals & Architecture (Hard).

TOTAL QUESTIONS

THEORY QUESTIONS

IMPLEMENTATION FOLIOS

FREE QUESTIONS

5 / Level

Easy Level·20 Questions Total

Foundations & Core Concepts

Open Full Easy List

Q1What is Prisma and what are its components?

Type-safe ORM for Node/TypeScript: schema.prisma (single source of truth), Prisma Migrate (declarative migrations), Prisma Client (generated typed query builder), Studio (GUI).
Replaces hand-written SQL strings with autocomplete-checked APIs - runtime errors become compile errors.

Q2What does schema.prisma contain?

Three blocks:

datasource (provider postgres/sqlite/mysql, url from env).
generator (client output).
model definitions with fields, types, attributes (@id, @default, @relation, @@index, @@unique). Everything - DB shape AND client API - derives from this file.

Q3How do you define a one-to-many relation?

model Author {
  id    Int    @id @default(autoincrement())
  books Book[]
}
model Book {
  id       Int    @id @default(autoincrement())
  author   Author @relation(fields: [authorId], references: [id])
  authorId Int
}

Scalar FK field (authorId) explicit + @relation wiring; back-relation list on the other side.
onDelete defaults: required relation → Restrict, optional → SetNull.

Q4What is prisma generate and when must it run?

Reads schema producing typed client into node_modules/.prisma - run after ANY schema change (postinstall hook recommended in CI/deploy).
Forgetting it after pull/migrate = "Property X does not exist" TS errors - the classic first-week mistake.

Q5What CRUD basics does the client provide?

await prisma.user.create({ data: { email } });
await prisma.user.findUnique({ where: { email } });
await prisma.user.update({ where: { id }, data: { name } });
await prisma.user.deleteMany({ where: { inactive: true } });
findMany({ take, skip, orderBy, where })

All fully typed from schema; filters compose nested objects; unique fields enable findUnique.

15 More Easy Questions Locked

Unlock the complete Prisma Easy question bank

Get instant access to all 20 questions, in-depth model answers, code sandboxes, and all 27+ technologies for a single one-time payment.

Unlock All — One-time payment · Lifetime access

Medium Level·20 Questions Total

Mechanisms & Practical Patterns

Open Full Medium List

Q1What is the N+1 problem in Prisma and how do include/select fix it?

Looping for (const post of posts) post.author issues one query per iteration - the client does NOT auto-batch lazy access.
Fix: single findMany({ include: { author: true } }) producing two total queries (posts + IN-list of authors).
Detection: Prisma client query logging (log:["query"]) exposes the storm instantly.

Q2How do nested writes (mutation shorthand) behave transactionally?

prisma.user.update({
  where: { id }, data: { posts: { create: {...}, deleteMany: { published: false } } }
})

Nested create/update/deleteMany run INSIDE one implicit transaction - atomicity free without $transaction wrapper.
Limits: cross-model ordering logic beyond nesting still needs interactive transactions.

Q3What are relation load strategies (joins) in newer Prisma versions?

relationLoadStrategy: "join" (Postgres) emits LEFT JOINs fetching relations in ONE round trip vs classic two-query batch.
Choose join for latency-sensitive paths with wide networks; batch (default) often cheaper for huge child sets (row multiplication on joins).
Per-query choice - benchmark both directions on representative data.

Q4How does Prisma handle optimistic concurrency?

No @Version primitive natively; pattern: filter update by expected value:

prisma.doc.updateMany({ where: { id, version }, data: { content, version: { increment: 1 } } })

count===0 ⇒ concurrent modification → retry/merge UX.
updateMany bypasses unique checks returning count - deliberate semantics worth knowing.

Q5What are the interactive transaction limits and how do you design around them?

Defaults maxWait 2s / timeout 5s - long logic inside throws P2028.
Design: keep txns SHORT (pure DB mutations), move IO/computation outside, pass ids across boundaries; raise limits only deliberately with lock-spread awareness.
Interactive txns hold a connection - nested pool starvation under concurrency is the hidden cost.

15 More Medium Questions Locked

Unlock the complete Prisma Medium question bank

Get instant access to all 20 questions, in-depth model answers, code sandboxes, and all 27+ technologies for a single one-time payment.

Unlock All — One-time payment · Lifetime access

Hard Level·20 Questions Total

Internals & System Architecture

Open Full Hard List

Q1How does the query compiler/engine architecture shape performance characteristics?

Client serializes typed JSON queries over a Rust engine (query compiler plans SQL) - separate process communication historically, driver adapters now allow in-process pure-TS path.
Implications: serialization overhead per query visible at very high RPS; prepared statement reuse differs per adapter; raw-SQL escapes bypass planning entirely.
Diagnose with engine logs + PG pg_stat_statements comparing generated SQL quality against hand-tuned baselines.

Q2What is the exact lifecycle of migrations from schema edit to prod, including edge commands?

Edit schema → migrate dev --name x diffs against SHADOW db creating migration folder (migration_lock.toml guards provider).
Local apply + generate.
CI: migrate deploy against ephemeral DB verifying chain integrity + migrate diff drift check.
Prod pipeline: deploy-only runner with advisory locking; failed migration marked via resolve after manual fix. Edge: squashing old migrations (migrate dev --name squash) requires coordinated reset discipline across environments.

Q3What are the referential action defaults and their cross-database differences?

Optional relations default SetNull; required → Restrict on Postgres/MySQL; SQLite legacy emulation differs (onDelete: NoAction mapping to deferred enforcement quirks).
relationMode "prisma" (emulated FKs client-side) vs "foreignKeys" (native) - emulated mode loses DB-level integrity, breaks external writers; deprecated direction worth flagging. Migration-time enforcement changes require table rewrites on some engines - plan accordingly.

Q4How do you implement soft deletes GLOBALLY with correct relation filtering?

Client extension approach:

$extends({
  query: { $allModels: { async $allOperations({args,query,operation}) {
    if (["findMany","findFirst"].includes(operation)) inject notDeleted(args)
    ...

Plus rewriting delete→update. Traps: include-nested relations bypass top-level rewrite (must walk nested args recursively), aggregate counts, raw queries untouched, unique lookups returning deleted rows via findUnique need explicit filters. Comprehensive suites asserting deleted visibility across EVERY access path distinguish real implementations.

Q5What is the connection pool math under serverless (Vercel/Lambda)?

Each lambda instance opens own pool → connection explosion past provider limits.
Solutions ladder: Accelerate proxy pooling; PgBouncer transaction mode direct URL (+pgbouncer=true flag); global singleton client reuse within warm instance.
Math example: 1000 concurrent instances × pool 5 = 5000 connections vs PG max 200 → must centralize. Cold-start + first-query latency budgeting included in answer.

15 More Hard Questions Locked

Unlock the complete Prisma Hard question bank

Get instant access to all 20 questions, in-depth model answers, code sandboxes, and all 27+ technologies for a single one-time payment.

Unlock All — One-time payment · Lifetime access

DEDICATED LEVEL PAGES

Browse All Prisma Questions by Difficulty

Easy20 Questions

Core concepts, definitions, basic syntax, and first principles expected in round 1 screening.

VIEW FULL LIST

Medium20 Questions

Real-world mechanisms, state management, edge cases, performance trade-offs, and practical coding.

VIEW FULL LIST

Hard20 Questions

Deep runtime internals, memory models, distributed design, concurrency failure modes, and architectural decisions.

VIEW FULL LIST

INTERNAL LINKING & DEPENDENCIES

Related Technologies to Prisma

CAREER PATHWAYS

Prisma is a key requirement for these engineering roles:

Backend Engineer Guide

DEVPREP CODEX · #20

Prisma Interview Questions

60 curated questions graded from Foundations (Easy) to Practical Patterns (Medium) and Internals & Architecture (Hard).

TOTAL QUESTIONS

THEORY QUESTIONS

IMPLEMENTATION FOLIOS

FREE QUESTIONS

5 / Level

Easy Level·20 Questions Total

Foundations & Core Concepts

Open Full Easy List

Q1What is Prisma and what are its components?

Type-safe ORM for Node/TypeScript: schema.prisma (single source of truth), Prisma Migrate (declarative migrations), Prisma Client (generated typed query builder), Studio (GUI).
Replaces hand-written SQL strings with autocomplete-checked APIs - runtime errors become compile errors.

Q2What does schema.prisma contain?

Three blocks:

datasource (provider postgres/sqlite/mysql, url from env).
generator (client output).
model definitions with fields, types, attributes (@id, @default, @relation, @@index, @@unique). Everything - DB shape AND client API - derives from this file.

Q3How do you define a one-to-many relation?

model Author {
  id    Int    @id @default(autoincrement())
  books Book[]
}
model Book {
  id       Int    @id @default(autoincrement())
  author   Author @relation(fields: [authorId], references: [id])
  authorId Int
}

Scalar FK field (authorId) explicit + @relation wiring; back-relation list on the other side.
onDelete defaults: required relation → Restrict, optional → SetNull.

Q4What is prisma generate and when must it run?

Reads schema producing typed client into node_modules/.prisma - run after ANY schema change (postinstall hook recommended in CI/deploy).
Forgetting it after pull/migrate = "Property X does not exist" TS errors - the classic first-week mistake.

Q5What CRUD basics does the client provide?

await prisma.user.create({ data: { email } });
await prisma.user.findUnique({ where: { email } });
await prisma.user.update({ where: { id }, data: { name } });
await prisma.user.deleteMany({ where: { inactive: true } });
findMany({ take, skip, orderBy, where })

All fully typed from schema; filters compose nested objects; unique fields enable findUnique.

15 More Easy Questions Locked

Unlock the complete Prisma Easy question bank

Get instant access to all 20 questions, in-depth model answers, code sandboxes, and all 27+ technologies for a single one-time payment.

Unlock All — One-time payment · Lifetime access

Medium Level·20 Questions Total

Mechanisms & Practical Patterns

Open Full Medium List

Q1What is the N+1 problem in Prisma and how do include/select fix it?

Looping for (const post of posts) post.author issues one query per iteration - the client does NOT auto-batch lazy access.
Fix: single findMany({ include: { author: true } }) producing two total queries (posts + IN-list of authors).
Detection: Prisma client query logging (log:["query"]) exposes the storm instantly.

Q2How do nested writes (mutation shorthand) behave transactionally?

prisma.user.update({
  where: { id }, data: { posts: { create: {...}, deleteMany: { published: false } } }
})

Nested create/update/deleteMany run INSIDE one implicit transaction - atomicity free without $transaction wrapper.
Limits: cross-model ordering logic beyond nesting still needs interactive transactions.

Q3What are relation load strategies (joins) in newer Prisma versions?

relationLoadStrategy: "join" (Postgres) emits LEFT JOINs fetching relations in ONE round trip vs classic two-query batch.
Choose join for latency-sensitive paths with wide networks; batch (default) often cheaper for huge child sets (row multiplication on joins).
Per-query choice - benchmark both directions on representative data.

Q4How does Prisma handle optimistic concurrency?

No @Version primitive natively; pattern: filter update by expected value:

prisma.doc.updateMany({ where: { id, version }, data: { content, version: { increment: 1 } } })

count===0 ⇒ concurrent modification → retry/merge UX.
updateMany bypasses unique checks returning count - deliberate semantics worth knowing.

Q5What are the interactive transaction limits and how do you design around them?

Defaults maxWait 2s / timeout 5s - long logic inside throws P2028.
Design: keep txns SHORT (pure DB mutations), move IO/computation outside, pass ids across boundaries; raise limits only deliberately with lock-spread awareness.
Interactive txns hold a connection - nested pool starvation under concurrency is the hidden cost.

15 More Medium Questions Locked

Unlock the complete Prisma Medium question bank

Get instant access to all 20 questions, in-depth model answers, code sandboxes, and all 27+ technologies for a single one-time payment.

Unlock All — One-time payment · Lifetime access

Hard Level·20 Questions Total

Internals & System Architecture

Open Full Hard List

Q1How does the query compiler/engine architecture shape performance characteristics?

Client serializes typed JSON queries over a Rust engine (query compiler plans SQL) - separate process communication historically, driver adapters now allow in-process pure-TS path.
Implications: serialization overhead per query visible at very high RPS; prepared statement reuse differs per adapter; raw-SQL escapes bypass planning entirely.
Diagnose with engine logs + PG pg_stat_statements comparing generated SQL quality against hand-tuned baselines.

Q2What is the exact lifecycle of migrations from schema edit to prod, including edge commands?

Edit schema → migrate dev --name x diffs against SHADOW db creating migration folder (migration_lock.toml guards provider).
Local apply + generate.
CI: migrate deploy against ephemeral DB verifying chain integrity + migrate diff drift check.
Prod pipeline: deploy-only runner with advisory locking; failed migration marked via resolve after manual fix. Edge: squashing old migrations (migrate dev --name squash) requires coordinated reset discipline across environments.

Q3What are the referential action defaults and their cross-database differences?

Optional relations default SetNull; required → Restrict on Postgres/MySQL; SQLite legacy emulation differs (onDelete: NoAction mapping to deferred enforcement quirks).
relationMode "prisma" (emulated FKs client-side) vs "foreignKeys" (native) - emulated mode loses DB-level integrity, breaks external writers; deprecated direction worth flagging. Migration-time enforcement changes require table rewrites on some engines - plan accordingly.

Q4How do you implement soft deletes GLOBALLY with correct relation filtering?

Client extension approach:

$extends({
  query: { $allModels: { async $allOperations({args,query,operation}) {
    if (["findMany","findFirst"].includes(operation)) inject notDeleted(args)
    ...

Q5What is the connection pool math under serverless (Vercel/Lambda)?

Each lambda instance opens own pool → connection explosion past provider limits.
Solutions ladder: Accelerate proxy pooling; PgBouncer transaction mode direct URL (+pgbouncer=true flag); global singleton client reuse within warm instance.
Math example: 1000 concurrent instances × pool 5 = 5000 connections vs PG max 200 → must centralize. Cold-start + first-query latency budgeting included in answer.

15 More Hard Questions Locked