Prisma vs Drizzle vs TypeORM: Choosing a TypeScript ORM as Prisma 8, Drizzle v1 and TypeORM 1.0 Arrive

Picking an ORM for a new TypeScript backend used to be a fairly settled conversation. This autumn it isn’t, because all three of the popular options are in the middle of major version changes at the same time. TypeORM finally shipped 1.0 in May 2026. Drizzle’s v1 is at release candidate stage. And Prisma 8, a ground-up redesign, is now what you get from npm install prisma, even though it is still a release candidate.

This guide compares Prisma, Drizzle and TypeORM as they stand in October 2026: how each one models your database, what the same small query looks like in each, what the current version changes mean for you, and which one fits which kind of project. The examples use PostgreSQL with the versions listed below. They type-check under TypeScript 7.0 and run against PostgreSQL 16.

Where each project stands right now

Version numbers come from the npm registry and each project’s own release pages. They move quickly, so check them again before you start.

The Prisma install trap

One thing in that table needs a warning before anything else. In late August Prisma moved the latest tag of the prisma CLI package to Prisma 8, and Prisma 7 now lives under the prev tag. At the time of writing, prisma@latest resolves to 8.0.0-rc.22 while @prisma/client@latest is still 7.10.0. Prisma’s release status page tells Prisma 7 users to pin prisma and @prisma/client to ^7, and to use npx prisma@7 anywhere the version isn’t locked.

If you are starting or maintaining a Prisma 7 project, pin both packages explicitly:

npm install -D prisma@7
npm install @prisma/client@7 @prisma/adapter-pg pg

Prisma 7 gets bug fixes and security updates for 18 months after Prisma 8 reaches general availability, so there is no rush to move. Prisma 6 is on security-only support that ends on 19 November 2026.

The same query in all three

To make the differences concrete, each example below does the same job: a users table and a posts table, insert a user with one post, then read users whose email ends in @example.com along with their posts.

Prisma 7

Prisma keeps your data model in its own schema language. Prisma 7 replaced the old Rust query engine with a TypeScript client, ships as an ES module, generates the client into your source tree, and requires a driver adapter for every database.

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

datasource db {
  provider = "postgresql"
}

model User {
  id    Int     @id @default(autoincrement())
  email String  @unique
  name  String?
  posts Post[]
}

model Post {
  id       Int    @id @default(autoincrement())
  title    String
  author   User   @relation(fields: [authorId], references: [id])
  authorId Int
}

The database URL now lives in a Prisma config file rather than the schema (Prisma 7.10’s prisma init names it prisma7.config.ts). Then you create the client with an adapter and query it:

// lib/prisma.ts
import "dotenv/config";
import { PrismaPg } from "@prisma/adapter-pg";
import { PrismaClient } from "../generated/prisma/client";

const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL! });
export const prisma = new PrismaClient({ adapter });

// script.ts
import { prisma } from "./lib/prisma";

await prisma.user.create({
  data: {
    email: "ayesha@example.com",
    name: "Ayesha",
    posts: { create: { title: "Hello Prisma" } },
  },
});

const users = await prisma.user.findMany({
  where: { email: { endsWith: "@example.com" } },
  include: { posts: true },
});

Run npx prisma migrate dev --name init to create the tables and npx prisma generate to build the client. Your project needs "type": "module" and Node.js 20.19 or later.

Drizzle

Drizzle’s schema is plain TypeScript, and its main query API reads like SQL. There is no generate step for the client: types come straight from the table definitions.

// src/db/schema.ts
import { integer, pgTable, text } from "drizzle-orm/pg-core";

export const users = pgTable("users", {
  id: integer().primaryKey().generatedAlwaysAsIdentity(),
  email: text().notNull().unique(),
  name: text(),
});

export const posts = pgTable("posts", {
  id: integer().primaryKey().generatedAlwaysAsIdentity(),
  title: text().notNull(),
  authorId: integer("author_id").notNull().references(() => users.id),
});

// src/index.ts
import "dotenv/config";
import { drizzle } from "drizzle-orm/node-postgres";
import { eq, like } from "drizzle-orm";
import { users, posts } from "./db/schema";

const db = drizzle(process.env.DATABASE_URL!);

const [user] = await db
  .insert(users)
  .values({ email: "ayesha@example.com", name: "Ayesha" })
  .returning();
await db.insert(posts).values({ title: "Hello Drizzle", authorId: user.id });

const rows = await db
  .select({ email: users.email, title: posts.title })
  .from(users)
  .innerJoin(posts, eq(posts.authorId, users.id))
  .where(like(users.email, "%@example.com"));

Add a drizzle.config.ts pointing at the schema, then npx drizzle-kit generate and npx drizzle-kit migrate. This exact code works on both the stable 0.45 line and the 1.0 release candidate. Note the trade-off it shows: the join returns flat rows, and you write the join yourself. Drizzle also has a relational query API (db.query.users.findMany({ with: { posts: true } })) that returns nested objects, but that is the part that changes most in v1, as covered below.

TypeORM 1.x

TypeORM describes tables as decorated classes, in a style familiar from Hibernate or Entity Framework. That is also why it pairs naturally with NestJS.

// entities.ts
import { Entity, PrimaryGeneratedColumn, Column, OneToMany, ManyToOne } from "typeorm";

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

  @Column({ type: "text", unique: true })
  email!: string;

  @Column({ type: "text", nullable: true })
  name!: string | null;

  @OneToMany(() => Post, (post) => post.author, { cascade: true })
  posts!: Post[];
}

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

  @Column({ type: "text" })
  title!: string;

  @ManyToOne(() => User, (user) => user.posts, { nullable: false })
  author!: User;
}

// index.ts
import "reflect-metadata";
import "dotenv/config";
import { DataSource, Like } from "typeorm";
import { User, Post } from "./entities";

const AppDataSource = new DataSource({
  type: "postgres",
  url: process.env.DATABASE_URL,
  entities: [User, Post],
  synchronize: true, // development only: use migrations in production
});

await AppDataSource.initialize();
const userRepo = AppDataSource.getRepository(User);

await userRepo.save(
  userRepo.create({
    email: "ayesha@example.com",
    name: "Ayesha",
    posts: [{ title: "Hello TypeORM" }],
  }),
);

const users = await userRepo.find({
  where: { email: Like("%@example.com") },
  relations: { posts: true },
});

Two practical details. TypeORM needs experimentalDecorators and emitDecoratorMetadata in tsconfig.json. And if you run TypeScript through esbuild-based tools such as tsx, decorator metadata is not emitted, so TypeORM cannot guess column types. Giving every @Column an explicit type, as above, avoids that error entirely.

What the new versions change

Prisma 8: a new API on top of a familiar schema

Prisma describes version 8 as “a ground-up rethink of Prisma.” It adds TypeScript schemas as an alternative to schema.prisma, migrations written as TypeScript files, and a small core with features such as PostgreSQL support supplied as extensions. Most importantly for existing code, the query API is different. Prisma’s own changelog gives the example that findMany becomes db.orm.public.User.where(...).all().

The migration story is reasonable. As of 2 October, Prisma 8 can read an existing Prisma 7 PostgreSQL schema unchanged, and both versions can run side by side against the same database while you move code over one module at a time. Views and a few other Prisma 7 features are not supported yet. My recommendation is to keep production apps on Prisma 7 until 8 reaches general availability and the API settles, and to try 8 on a branch or a new side project first.

Prisma users should also note two retirement dates from the same changelog: Prisma Postgres Early Access databases are deleted on 1 November 2026, and Prisma Accelerate is retired on 1 December 2026. If your connection string contains accelerate.prisma-data.net, or your queries use cacheStrategy, you have work to do before then.

Drizzle v1: relations and migrations

Drizzle’s 1.0 release candidate is installed with the @rc tag. The two changes most projects will notice are:

• Relational Queries v2. If you use db.query with relations, the upgrade guide says you need to move to the v2 relations API. The SQL-like builder used above is unaffected.
• A new migrations layout. The journal.json file is gone, each migration gets its own folder with its SQL and snapshot, and drizzle-kit can detect migrations that conflict across branches. npx drizzle-kit up converts an existing folder.

For a new project today, starting on the release candidate avoids a migration later. For an existing production app, waiting for the stable 1.0 is the safer choice.

TypeORM 1.0: a cleanup, not a rewrite

TypeORM’s 1.0 is mostly about removing old APIs that had been deprecated for years. Connection is gone in favour of DataSource, as are the global helpers like getRepository(), @EntityRepository (use Repository.extend()), findByIds, and string arrays for select and relations. Node.js 20 or later is required, MySQL support uses only mysql2, and SQLite uses better-sqlite3. One behaviour change can catch you out: null or undefined in a where condition now throws by default instead of being silently ignored. A @typeorm/codemod package automates most of the upgrade from 0.3.

The bigger news is the project’s health. TypeORM’s maintainers say that in 2025 they merged 575 pull requests, up from 63 the year before, and closed more than 2,300 issues. Concerns about TypeORM being abandoned, which were common a couple of years ago, are much weaker now. The @nestjs/typeorm package’s peer dependency range already accepts TypeORM 1.x.

How to choose

None of these is the “fast” or “correct” one in general, and performance claims from each project are measured on their own benchmarks. For most web apps, query design and indexes matter far more than ORM overhead. Choose on how you want to work:

• Choose Drizzle if you think in SQL, want the schema to be ordinary TypeScript, and want no code generation step. It also suits serverless and edge runtimes well because it is a thin layer over your database driver.
• Choose Prisma 7 if you want the most readable data model and query API for a team, nested writes and reads without writing joins, and polished tooling such as Prisma Studio. Accept that a large API change (Prisma 8) is coming within the support window.
• Choose TypeORM if you are building with NestJS or come from a class-based ORM background, or you already have a TypeORM codebase. With 1.0 out and active maintenance, upgrading an existing app is now a better plan than rewriting it.

Whichever you pick, a few habits apply to all three: keep migrations in version control and review the generated SQL, never use schema “push” or synchronize against production, and learn to read your database’s query plans, because every ORM can generate a slow query.

Sources: Prisma ORM release status, Prisma changelog, 2 October 2026, Prisma changelog, 28 August 2026, Prisma 8 blog series, Announcing Prisma ORM 7, Upgrade to Prisma ORM 7, Prisma 7 PostgreSQL quickstart, Drizzle: Get started with PostgreSQL, Upgrading to Drizzle v1 RC, TypeORM blog: TypeORM 1.0 is here, TypeORM 1.0 release notes, npm registry

Related reading

• PostgreSQL 19: The New Features That Made It (and the Ones Pulled Before Release)
• PostgreSQL EXPLAIN ANALYZE: How to Read Query Plans and Tune Costs (Real Examples)
• TypeScript 7 Is Here: What the Go Compiler Changes, and What Angular Developers Should Do Now