Can Prisma preserve mixed‑case PostgreSQL column names in production?

Direct Answer

Prisma cannot preserve mixed-case identifiers in the Prisma field names themselves — introspection always normalizes them to lower camelCase (e.g., userId). However, Prisma does preserve the original PostgreSQL column case automatically via @map("UserID") annotations on each field, and Prisma Migrate honors those mappings in production. No manual schema edits are required after each prisma db pull.

Confirmed Behavior

• Introspection output: A PostgreSQL column named "UserID" becomes a Prisma field userId with @map("UserID") attached automatically.
• Runtime queries: Prisma Client generates SQL that references the exact mixed-case column name because the @map directive is applied during query compilation.
• Migrations: prisma migrate deploy creates and updates columns using the quoted, mixed-case identifiers from @map.
• No toggle exists: As of the Prisma 5.x/6.x line there is no documented configuration option, preview flag, or generator setting that makes introspection keep the original casing in the Prisma field name. Check the Prisma changelog before assuming this has changed.

Recommended Workflow

1. Run prisma db pull against your development database.
2. Commit the generated schema.prisma (including all @map annotations) to version control.
3. Deploy the same schema to production; prisma migrate deploy applies the quoted column names correctly.
4. When the PostgreSQL schema changes, re-run prisma db pull — Prisma updates both normalized field names and @map values automatically.

Critical Cautions

• Never remove @map directives. Doing so causes Prisma to query lower-case column names that do not exist.
• Raw SQL bypasses @map. Any prisma.$queryRaw or $executeRaw must reference mixed-case identifiers with double quotes (e.g., "UserID").
• Table names behave the same way. Mixed-case table names are mapped via @@map("UserTable") on the model.

Verification Step

Create a test table with a mixed-case column, run prisma db pull, and confirm the generated field carries @map("UserID"). Then execute a Prisma query (e.g., findUnique) against a staging database and inspect the executed SQL (enable DEBUG=prisma:query) to verify the column reference matches the original case.

One Diagnostic Detail

Are you using Prisma Migrate for production deployments, or applying schema changes via raw SQL or external tools? If the latter, the @map annotations in your Prisma schema are not enforced automatically, and you must ensure the target database columns match the quoted names exactly.