A backend or full-stack developer working primarily in TypeScript who uses Prisma
as their database interface and considers the Prisma schema file to be the
authoritative source of truth for their data model. They came from raw SQL,
or from another ORM, and found that Prisma's type generation changed how they
think about database access — not as a string-query problem but as a typed function
call where the compiler tells them when something is wrong before it runs.
They have strong feelings about the Prisma schema. Those feelings are mostly fond.
Intention
What are they trying to do? —
Outcome
What do they produce? —
Goals
→Write database queries that are type-safe end-to-end, from schema to response
→Evolve the database schema through migrations that are generated automatically
→from schema changes
→Query relational data with enough expressiveness that they don't reach for raw SQL
→for standard operations
Frustrations
—Prisma queries that are fast for simple cases and generate problematic SQL for
—complex relational queries — the N+1 problem that requires `include` restructuring
—Migration history in team environments where multiple developers change the schema
—on different branches simultaneously
—The Prisma Data Platform pricing conversation that happens when they want
—features beyond the local ORM
—Edge runtime compatibility that requires switching to Prisma's Accelerate for
—serverless deployments at Vercel or Cloudflare Workers
Worldview
Type safety is not a luxury — it's documentation that's enforced at compile time
The schema file is the contract between the application and the database;
it should be version-controlled and human-readable
An ORM that generates bad SQL is a liability that only shows up at scale
Scenario
They're adding a new feature: a dashboard that shows each user their top 10
most-used features with usage counts over the last 30 days. They're writing
the Prisma query. The first version uses `findMany` with `include` and generates
12 database calls for a list of 100 users. They're rewriting it with aggregation.
The Prisma Client API doesn't support the exact aggregation they need.
They're about to write a `$queryRaw` for this one specific case.
They're slightly annoyed. It's the right call.
Context
Uses Prisma in a TypeScript application with PostgreSQL or MySQL. Has a Prisma schema
with 15–50 models and their relationships. Runs `prisma migrate dev` as part of
their development workflow and `prisma migrate deploy` in CI. Uses Prisma Studio
occasionally for quick data inspection. Has Prisma Client generated and imported
in 10–30 service or repository files. Has a baseline migration from an existing
database they inherited. Has encountered at least one migration conflict in a
team setting and resolved it with a manual merge.
Impact
→Query plan analysis built into Prisma Studio or the CLI that surfaces N+1 patterns
→before they reach production removes the performance discovery at scale
→Branch-aware migration management that understands which migrations are on which
→branch reduces the conflict resolution ceremony in multi-developer schema evolution
→Native aggregation support that covers common analytical patterns (sum, count by group,
→date trunc) reduces the `$queryRaw` fallback rate for standard reporting queries
→Edge runtime native support without a separate connection proxy product removes
→the architecture decision between Prisma local and Prisma Accelerate for serverless targets
Composability Notes
Pairs with `supabase-primary-user` for developers who use Supabase's PostgreSQL with Prisma as the ORM layer.
Contrast with `data-engineer` for the application data access vs. analytics data pipeline database philosophy.
Use with `vercel-primary-user` for the full TypeScript stack deployment where Prisma's edge compatibility matters.