Prisma ORM: A Complete Guide for Node.js Developers

Prisma replaces hand-written SQL strings and loose model classes with one schema file and a fully typed client. It is a great fit for TypeScript projects.

The schema is the source of truth

model Post {
  id        String   @id @default(cuid())
  title     String
  slug      String   @unique
  author    User     @relation(fields: [authorId], references: [id])
  authorId  String
  createdAt DateTime @default(now())
}

From this file Prisma generates a client whose methods and return types match your models exactly. Rename a field and TypeScript points at every place that breaks.

Relations without the boilerplate

Use include to load related records and select to pick only the fields you need. Prefer select on list endpoints; it keeps payloads small and queries fast.

Migrations

For SQL databases, prisma migrate dev creates a versioned migration you commit to git, and prisma migrate deploy applies it in production. For MongoDB, prisma db push syncs the schema because there are no SQL migrations.

Transactions

Use $transaction when several writes must succeed or fail together, such as creating an order and decrementing stock.

await prisma.$transaction([
  prisma.order.create({ data }),
  prisma.product.update({ where: { id }, data: { stock: { decrement: 1 } } }),
]);

Performance traps

• N+1 queries: loading related rows in a loop. Use include or a single findMany with in.
• Missing indexes: add @@index for fields you filter and sort by.
• Over-fetching: returning big text columns on list pages. Omit them.

Switching databases

Because your code talks to the Prisma client, moving from MongoDB to PostgreSQL mostly means changing the provider and a few ID and JSON details, not rewriting queries. That portability is a real advantage.

Takeaway

Treat the schema as a design document, select only what you need, and wrap related writes in transactions.