7 Powerful Prisma Patterns for Your 2025 Projects

4. Blazing-Fast Pagination with Cursors

As your data grows, simple offset-based pagination (using `skip` and `take`) becomes inefficient. It forces the database to count through all the skipped rows on every request. Cursor-based pagination provides a high-performance alternative.

What is it?

Instead of telling the database how many items to `skip`, you provide a `cursor`—a pointer to the last item you saw (usually its unique ID). The database can then jump directly to that point and fetch the next `take` items.

How to Implement It

Your API endpoint would take an optional `cursor` parameter. The first request has no cursor.

// Example API route (e.g., in Next.js)
import prisma from '@/lib/prisma'

export async function getPosts(cursor?: string) {
  const take = 10

  const posts = await prisma.post.findMany({
    take,
    // If a cursor is provided, skip one (the cursor itself) and start from there
    skip: cursor ? 1 : 0,
    // The cursor points to the last record from the previous page
    cursor: cursor ? { id: cursor } : undefined,
    orderBy: {
      createdAt: 'desc',
    },
  })

  const nextCursor = posts.length === take ? posts[take - 1].id : null

  return {
    posts,
    nextCursor,
  }
}

Your frontend receives `posts` and `nextCursor`. For the next request (e.g., when the user scrolls), it sends the `nextCursor` value back to the API.

5. Implementing "Soft Deletes" Like a Pro

Sometimes, you don't want to permanently delete data. You want to hide it, but keep it in the database for auditing, analytics, or potential restoration. This is called a "soft delete," and Prisma middleware makes implementing it elegantly simple.

What is it?

You add a field like `deletedAt` (a `DateTime?`) to your models. Instead of running a `DELETE` SQL command, a soft delete performs an `UPDATE` to set the `deletedAt` timestamp. You then filter out these "deleted" records from all your `find` queries.

How to Implement It

We can use Prisma middleware to intercept `delete` and `find` queries automatically. This is incredibly powerful because your application code doesn't need to change at all—it just keeps calling `prisma.user.delete()`.

// Add to your extended client setup from Pattern 1
const prisma = new PrismaClient()

const softDeletePrisma = prisma.$extends({
  query: {
    // Add for every model you want to soft delete
    user: {
      // 1. Intercept 'delete' and 'deleteMany' and turn them into 'update'
      async delete({ model, args }) {
        return prisma.user.update({
          where: args.where,
          data: { deletedAt: new Date() },
        })
      },

      // 2. Intercept 'find' queries to exclude soft-deleted records
      async findMany({ model, args, query }) {
        args.where = { ...args.where, deletedAt: null }
        return query(args)
      },
      async findUnique({ model, args, query }) {
        args.where = { ...args.where, deletedAt: null }
        return query(args)
      },
      // ... add for findFirst, count, etc.
    },
  },
});

export default softDeletePrisma

6. End-to-End Type Safety with Prisma.validator

One of Prisma's core promises is type safety. But how do you ensure the types you define for your API responses or frontend components perfectly match the data you've selected from the database? `Prisma.validator` is the key.

What is it?

Prisma.validator allows you to create a reusable query definition (including `select` and `include` clauses) and, more importantly, derive a TypeScript type from it. This means if you change your query, your TypeScript types will automatically update (or break, telling you to fix them!).

How to Implement It

Let's define a reusable query for a user with their posts and derive a type from it.

import { Prisma } from '@prisma/client'

// 1. Define the query arguments using a validator
const userWithPostsArgs = Prisma.validator<Prisma.UserArgs>()({
  include: { posts: { select: { id: true, title: true } } },
})

// 2. Derive the type for the payload
export type UserWithPosts = Prisma.UserGetPayload<typeof userWithPostsArgs>

// 3. Use them together in a function
async function findUserWithPosts(userId: string): Promise<UserWithPosts | null> {
  return prisma.user.findUnique({
    where: { id: userId },
    ...userWithPostsArgs, // Spread the reusable args
  })
}

Now, the `UserWithPosts` type is guaranteed to match the shape of the data returned by `findUserWithPosts`. You can export this type and use it in your API layers (like tRPC) or directly in your frontend components for perfect type safety.

7. The "Raw Query" Escape Hatch for Peak Performance

While Prisma's query engine is highly optimized, there are rare cases where you need to drop down to raw SQL for maximum performance or to use a database feature Prisma doesn't yet support (like certain PostGIS functions).

What is it?

Prisma provides `queryRaw` and `executeRaw` as safe "escape hatches." They allow you to write raw SQL while still providing protection against SQL injection attacks through parameterized queries.

How to Implement It

Use `queryRaw` for queries that return data and `executeRaw` for those that don't (like `UPDATE` or `DELETE`). Let's say we need a complex report that's easier to write in SQL.

import { Prisma } from '@prisma/client'
import prisma from '@/lib/prisma'

async function getMonthlyUserSignups(year: number) {
  const result = await prisma.$queryRaw<{ month: number; count: BigInt }[]>`
    SELECT 
      EXTRACT(MONTH FROM "createdAt") as month,
      COUNT(*) as count
    FROM "User"
    WHERE EXTRACT(YEAR FROM "createdAt") = ${year}
    GROUP BY month
    ORDER BY month ASC;
  `
  // Note: COUNT returns BigInt, you may need to convert it
  return result.map(r => ({ ...r, count: Number(r.count) }))
}

When to use this? Be cautious. This is a powerful tool, but it bypasses many of Prisma's abstractions. Use it for performance-critical analytics, complex joins that are awkward in the Prisma API, or when using database-specific features.