What is an ORM, and why did my AI add Prisma?

What it actually is

An ORM, short for object-relational mapper, is a library that sits between your code and your database and translates between the two. Instead of your agent writing SELECT * FROM users WHERE email = ... by hand, it calls a function like prisma.user.findUnique({ where: { email } }), and the ORM turns that into the real SQL for your specific database, then hands the result back as a plain object your code can use.

Think of it as a translator standing between you and someone who only speaks SQL. You describe what you want in your own language, a function call your agent already knows how to write. The translator carries that request across and hands the answer back in a shape you can use directly, not a raw block of database output you’d have to parse yourself.

The piece holding it together is the schema file: schema.prisma for Prisma, a set of TypeScript files for Drizzle. It lists every table, column, and relationship once. The generated client, the SQL, and the migration files all come from that one file. Change the schema, and the rest follows.

Why your AI just did this

Two things pull your agent toward an ORM instead of writing SQL by hand. The first is types. Prisma Client reads your schema and generates matching TypeScript types, so if your agent writes user.emial instead of user.email, the type checker catches the typo before the code runs, the same way it catches any other shape mismatch in a typed project. That matters more as a project grows: an agent writing dozens of queries benefits from a reviewer that checks every one for free.

The second is safety. Raw SQL built by joining strings together is the classic route to a SQL injection bug: user input landing directly inside a query string can change what the query does. Prisma Client’s typed functions, and its $queryRaw tagged-template method, send your values as separate parameters instead of pasting them into the SQL text, so the database treats them as data, not as code to run. Your agent doesn’t have to remember to escape anything, because the library does it by default.

Migrations round out the picture. Prisma Migrate and Drizzle Kit turn a schema change into a dated, reviewable SQL file instead of a manual ALTER TABLE you’d write yourself, filed right in your repo, so a database migration shows up in your git history like any other change.

When you’ll run into it

You’ll usually see the schema file appear first, prisma/schema.prisma or a db/schema.ts in a Drizzle project, right after your agent wires up a database. Soon after, a prisma/migrations/ folder shows up, full of timestamped subfolders, each holding a migration.sql your agent generated rather than wrote from scratch.

Running npx prisma migrate dev is the moment the schema and the real database sync up: Prisma compares your schema against the migration history, generates SQL for whatever changed, and applies it. Prisma’s own documentation is direct that this command is for development only and should never run against a production database; prisma migrate deploy handles production instead, applying migrations that already exist without touching your schema. A Drizzle project follows the same shape with different names: npx drizzle-kit generate writes the SQL file, npx drizzle-kit migrate applies it.

Two errors show up often enough to recognize on sight. Environment variable not found: DATABASE_URL. means Prisma Client can’t find your connection string, usually because it isn’t set where the running process can see it. Unique constraint failed on the fields: (`email`), Prisma’s error code P2002, means you tried to insert or update a row with a value a column already has marked unique, like signing up with an email that’s already registered.

What to check

• Open the schema file before asking your agent to change anything else. It’s the one place that lists every table and column, in plain enough syntax to follow even without SQL
• Before running a migrate command against a database with real data, confirm you’re using the production-safe path (prisma migrate deploy, or Drizzle’s equivalent), not the development one
• If your agent writes raw SQL anywhere, check it uses the tagged-template form ($queryRaw with your values passed in) rather than a method with “unsafe” in its name
• Read the migration file before applying it to real data. A generated column drop or table rename can delete data that a schema diff alone won’t warn you about
• If an error names a field you don’t recognize, check the schema file for a typo or a missing relationship first
• Ask which ORM the project actually uses before assuming Prisma. Drizzle’s schema lives in plain TypeScript files, not a .prisma file, with different migration commands

Say it like a dev

Instead of: “the database thing broke, something about Prisma” Say: “I’m getting a Prisma error. Can you paste the exact message and error code, like P2002, so I know what it means before we fix it?”

Instead of: “just delete the table and start over” Say: “Before you drop or recreate anything, show me the migration file you’re about to run so I understand what changes.”

Instead of: “make it use SQL directly instead of whatever this is” Say: “If this needs raw SQL, use the tagged-template version that parameterizes my values instead of building the query as a string.”