Prisma Interview Questions — Hard

• 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.

---

1. Edit schema → migrate dev --name x diffs against SHADOW db creating migration folder (migration_lock.toml guards provider).
2. Local apply + generate.
3. CI: migrate deploy against ephemeral DB verifying chain integrity + migrate diff drift check.
4. 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.

---

• 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.

---

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.

---

• 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.

---