TypeORM or Prisma: integrating an ORM

TypeORM: entities are the truth, repositories are injected

In the TypeORM path you configure a single DataSource once at the root, then register entities per feature module. The connection is async because its values come from ConfigService, so you reach for TypeOrmModule.forRootAsync with a useFactory rather than the static forRoot:

import { Module } from '@nestjs/common';
import { TypeOrmModule } from '@nestjs/typeorm';
import { ConfigModule, ConfigService } from '@nestjs/config';
import { User } from './user.entity';

@Module({
  imports: [
    TypeOrmModule.forRootAsync({
      imports: [ConfigModule],
      inject: [ConfigService],
      useFactory: (config: ConfigService) => ({
        type: 'postgres',
        host: config.get('DB_HOST'),
        port: config.get<number>('DB_PORT'),
        username: config.get('DB_USER'),
        password: config.get('DB_PASS'),
        database: config.get('DB_NAME'),
        entities: [User],
        synchronize: false, // NEVER true in production
      }),
    }),
  ],
})
export class AppModule {}

The entity is a plain class decorated with @Entity(), and its columns are the schema:

import { Entity, PrimaryGeneratedColumn, Column } from 'typeorm';

@Entity()
export class User {
  @PrimaryGeneratedColumn()
  id: number;

  @Column({ unique: true })
  email: string;

  @Column({ default: true })
  isActive: boolean;
}

That decorator metadata is the type-safety source of truth — the TypeScript class drives both the runtime column mapping and the migration generator. To use the entity in a feature module you register it with forFeature, which provides a repository for it into the DI container, and you inject that repository with @InjectRepository:

import { Module } from '@nestjs/common';
import { TypeOrmModule } from '@nestjs/typeorm';
import { User } from './user.entity';
import { UsersService } from './users.service';

@Module({
  imports: [TypeOrmModule.forFeature([User])], // provides Repository<User>
  providers: [UsersService],
})
export class UsersModule {}

import { Injectable } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';
import { User } from './user.entity';

@Injectable()
export class UsersService {
  constructor(
    @InjectRepository(User)
    private readonly users: Repository<User>,
  ) {}

  findActive(): Promise<User[]> {
    return this.users.find({ where: { isActive: true } });
  }
}

The Repository<User> is the persistence boundary: your service talks to it, never to raw SQL or a global client. This is DI-native — the repository is a normal Nest provider, mockable in tests by overriding the getRepositoryToken(User) provider.

Prisma: schema is the truth, you wrap the client yourself

Prisma inverts the source of truth. A single schema.prisma file declares the models; prisma generate reads it and emits a fully-typed client. You never write entity classes — the schema generates the types:

// schema.prisma
generator client {
  provider = "prisma-client-js"
}

model User {
  id       Int     @id @default(autoincrement())
  email    String  @unique
  isActive Boolean @default(true)
}

Nest has no first-class Prisma DI provider, so you supply one: an injectable PrismaService that extends the generated PrismaClient and opens the connection in onModuleInit. This is the integration glue you write by hand:

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

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

Provide it once, then inject the single service — there is no per-entity @InjectRepository, just typed model accessors on the client:

import { Injectable } from '@nestjs/common';
import { PrismaService } from './prisma.service';
import { User } from '@prisma/client';

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

  findActive(): Promise<User[]> {
    return this.prisma.user.findMany({ where: { isActive: true } });
  }
}

Note what’s missing: no forFeature, no repository token, no decorator on a model. The whole API surface is this.prisma.<model>.<operation>, and the User type comes from @prisma/client, regenerated every time the schema changes.

The real decision: where the truth lives

When you’re evaluating these options in a real PR, the vibe arguments stop mattering fast — the constraints don’t. Neither is universally correct — they differ on three axes a senior weighs against a stated constraint. The type-safety source of truth is the first: TypeScript decorator entities (TypeORM) versus a .prisma schema that generates the client (Prisma). Migrations follow from that: TypeORM generates and runs migration files derived from your entities; Prisma Migrate diffs the schema and produces SQL migrations. And DI ergonomics diverge: TypeORM gives you per-entity repositories as first-class Nest providers; Prisma gives you one client you wrap and inject everywhere.