Prisma ORM

Schema and Client Generation

schema.prisma is the single source of truth: a datasource block names the provider and URL, a generator emits the client, and models map to tables.

model User {
  id    Int    @id @default(autoincrement())
  email String @unique
  posts Post[]
}

Running npx prisma generate regenerates typed classes in node_modules/.prisma/client — after any schema edit, stale types mean the generate step was skipped. prisma migrate dev creates a migration file, applies it locally, and regenerates the client; CI and production use prisma migrate deploy to replay committed migrations without prompting.

Queries and Transactions

The client exposes CRUD plus relation filters; include loads relations in one typed call:

const users = await prisma.user.findMany({
  where: { email: { contains: "@" } },
  include: { posts: true },
});

await prisma.$transaction([
  prisma.user.create({ data: { email: "a@b.c" } }),
  prisma.post.create({ data: { title: "hi" } }),
]);

The array form batches statements in one transaction. The interactive form $transaction(async (tx) => {...}) runs arbitrary logic with a shared client and accepts an isolation level such as Serializable, which you need when reads and writes must not interleave.

Pitfalls and Interview Angles

N+1 reads. Looping over rows and calling findUnique per row issues one query each; use include or one where: { id: { in: ids } } query.

Generate is not automatic. CI that changes the schema but skips prisma generate compiles against old types — wire it into the build.

Types are not validation. Generated types describe what the database accepts; untrusted HTTP bodies still need runtime parsing (Zod or Valibot) before you trust them.

Interview: explain how Prisma translates the schema into a typed query engine client, compare migrate dev with migrate deploy, and say when the batch $transaction array is insufficient.