Step 2: Creating a Prisma Extension for Automatic Filtering

In older versions of Prisma, we used middleware. With modern Prisma versions, client extensions are the recommended way to intercept queries. We can write an extension that automatically injects deletedAt: null into every findMany and findFirst query.

Create a prisma.service.ts file in your NestJS project:

import { Injectable, OnModuleInit } from '@nestjs/common';
import { PrismaClient } from '@prisma/client';

@Injectable()
export class PrismaService extends PrismaClient implements OnModuleInit {
    async onModuleInit() {
        await this.$connect();
    }

    // Extend Prisma Client
    get extendedClient() {
        return this.$extends({
            query: {
                user: {
                    async findMany({ args, query }) {
                        args.where = { ...args.where, deletedAt: null };
                        return query(args);
                    },
                    async findFirst({ args, query }) {
                        args.where = { ...args.where, deletedAt: null };
                        return query(args);
                    },
                    async findUnique({ args, query }) {
                        // findUnique requires unique fields, so we use findFirst instead
                        return query(args);
                    },
                },
            },
        });
    }
}

Now, whenever your application calls prisma.user.findMany(), Prisma automatically appends the condition to ignore soft-deleted rows.

Step 3: Implementing the Soft Delete Method in Your Service

When a user requests account deletion, your NestJS service should not call prisma.user.delete(). Instead, it should perform an update operation.

import { Injectable, NotFoundException } from '@nestjs/common';
import { PrismaService } from './prisma.service';

@Injectable()
class UsersService {
    constructor(private prisma: PrismaService) {}

    async softDelete(id: string) {
        const user = await this.prisma.user.findFirst({
            where: { id, deletedAt: null },
        });

        if (!user) {
            throw new NotFoundException('User not found');
        }

        return this.prisma.user.update({
            where: { id },
            data: { deletedAt: new Date(), isActive: false },
        });
    }

    async restore(id: string) {
        return this.prisma.user.update({
            where: { id },
            data: { deletedAt: null, isActive: true },
        });
    }
}

Handling Relations and Cascades

Soft deletion gets tricky when dealing with relational data. If you soft-delete a company, what happens to its members?

In my projects, I usually handle relational soft deletes explicitly inside a Prisma transaction. If a parent record is soft-deleted, I run an update query to mark all related child records as deleted as well. This ensures that queries filtering by parent IDs do not accidentally pull orphaned child records.

Querying Deleted Records When Needed

Sometimes, admins need to view deleted records. Because our extension automatically filters them out, how do we query them? We can bypass the extension by accessing the base PrismaClient methods directly when writing admin-specific endpoints.

async findAllWithDeleted() {
    // Bypasses the extension to show everything
    return this.prisma.user.findMany();
}

Conclusion

Implementing soft deletes with NestJS, Prisma, and PostgreSQL gives you the best of both worlds: clean application code with automatic safety filters, and resilient database constraints that prevent unique key collisions.

If you need help architecting robust backend APIs, building custom SaaS products, or setting up complex databases for your clients, feel free to get in touch.