Database ORMs

The most polished schema-first TypeScript ORM. You write a schema.prisma declarative file, run prisma generate, and get a fully typed, ergonomic client. Prisma 7 (released November 19, 2025) replaced the Rust query engine with a TypeScript implementation, dramatically reducing bundle size and cold-start cost — the historic case against Prisma in serverless environments.

• Prisma 7 changes: Rust-free TypeScript runtime; bundle dropped from ~14 MB (7 MB gzipped) to ~1.6 MB (600 KB gzipped); 3.4× faster on findMany over 25K rows; 70% faster type checks; 98% fewer types evaluated per schema
• Generated code: Now lives outside node_modules — better caching and review
• Dynamic config: New prisma.config.ts separates project config from data schema
• Databases: PostgreSQL, MySQL, MariaDB, SQLite, MongoDB, CockroachDB, Microsoft SQL Server
• Tooling: Prisma Studio (GUI), Prisma Migrate (declarative migrations), Prisma Accelerate (managed connection pooling + caching)
• Documentation: Best-in-class — Prisma docs are the gold standard among ORMs

Limitations: Even after the Rust removal, the developer-experience trade is "Prisma owns your data layer." Schema language is bespoke (not SQL); migrations are declarative (not imperative SQL files you can hand-edit). Dropping below the abstraction is awkward. Pre-7 cold-start horror stories are still in the wild — older blog posts about Prisma + Lambda no longer reflect reality.

A pure TypeScript query builder with the strongest type inference in the ecosystem. Not really an ORM — you bring your own schema definitions and migration tool. What you get is autocomplete and type-checking on every column, alias, and join, including subqueries and CTEs. Pronounced "Key-Seh-Lee."

• Type system: Best-in-class — result types narrow correctly across joins, aliases, subqueries, with-statements, window functions
• Bundle: Lightweight, no runtime engine
• Runtimes: Node.js, Deno, Bun, Cloudflare Workers, browsers
• Databases: PostgreSQL, MySQL, SQLite via official dialects; community dialects for D1, Planetscale, Neon, etc.
• SQL features: Joins, subqueries, CTEs, window functions, aggregates, raw SQL escape hatches, transactions, DDL
• Used by: Deno, Maersk, Cal.com
• Migrations: Built-in migration runner with up/down TypeScript files

Limitations: No schema-from-code — you describe your tables/columns in a TypeScript interface and keep it in sync with the actual schema yourself (or use a generator like kysely-codegen). No relations API; you write joins explicitly. No GUI. Smaller community than Drizzle or Prisma; fewer tutorials.

Heritage TypeScript ORM that follows Hibernate / Entity Framework conventions. Models are classes with decorators; the ORM resolves relationships, lazy-loads, and handles cascade behavior. Supports both Active Record and Data Mapper patterns — rare among Node ORMs. After a leadership transition in late 2024 (Michael Bromley and David Hoeck under Elevantiq), maintenance is active again: 8 patch releases through 2025, 575 PRs merged, 2,300+ issues closed, and **TypeORM v1.0.0 shipped 2026-05-19**.

• Decorator-driven entities: @Entity, @Column, @OneToMany, etc. — familiar to Java/.NET developers
• Two patterns: Active Record (User.find()) or Data Mapper (userRepository.find())
• Databases: PostgreSQL, MySQL, MariaDB, SQLite, Microsoft SQL Server, Oracle, MongoDB, plus more via drivers
• Migrations: Generated from entity diffs; usable but less polished than Drizzle Kit or Prisma Migrate
• NestJS integration: First-class via @nestjs/typeorm — the default ORM for many NestJS codebases
• Maturity: Predates Prisma and Drizzle; large existing-codebase footprint

Limitations: Type inference is weaker than Prisma, Drizzle, or Kysely — you'll occasionally fight TypeScript on relations. Decorator metadata requires experimentalDecorators + emitDecoratorMetadata, which complicates some build setups (Bun, esbuild without plugins). Larger bundle and slower cold starts than Drizzle/Prisma 7. Post-v1.0.0 (May 2026) the historical 'spotty maintenance' framing no longer applies, but the legacy decorator-heavy API still feels heavy compared to modern alternatives.

The classic JavaScript ORM — predates TypeScript by years. Define models with field types and associations, get an Active Record-style API (User.findAll(), user.save()). Still ubiquitous in older Node codebases.

• Databases: PostgreSQL, MySQL, MariaDB, SQLite, Microsoft SQL Server, Snowflake, Db2
• Production version: v6 (stable, JavaScript-first with TypeScript types added)
• Next major: v7 has been in alpha for years — 48+ alpha releases, no beta as of early 2026
• Migrations: CLI-driven via sequelize-cli
• Hooks & lifecycle events: Rich set of before/after hooks on save, create, destroy
• Validations: Built-in field validators

Limitations: TypeScript support feels bolted on rather than native — types are accurate-ish but not as ergonomic as Prisma, Drizzle, or Kysely. v7 perpetual-alpha is a real signal: starting a new TypeScript-first project on Sequelize in 2026 is hard to defend. Better choice for teams already on Sequelize v6 with a working app, where migration cost outweighs benefit.

Skip the ORM and write SQL directly. Modern drivers like postgres.js (Porsager) make this safe via tagged template literals that auto-parameterize values. Knex.js sits a bit higher as a chainable query builder. You give up code-level type safety and migrations tooling, but you keep absolute control and zero abstraction overhead.

• postgres.js: Tagged-literal API, sql`select * from users where id = ${id}`, automatic parameterization, fastest fully-featured Postgres client for Node/Bun/Deno/Workers
• node-postgres (pg): Older, more conservative, stable — the historical default
• Knex.js: Mature SQL query builder with migration tool and seed runner; pre-Kysely standard
• sqltyper / SafeQL / Squid: Tools that generate TypeScript types from your raw SQL strings against a real database, giving you type safety without an ORM
• Migrations: Roll your own with node-pg-migrate, Knex migrations, or hand-written SQL files run via psql
• Bundle: Smallest possible — just the driver

Limitations: No schema-derived types unless you wire up a generator. No automatic migration drift detection. Refactors that touch column names break silently unless you have integration tests or codegen. Not the right call for teams that need to onboard mid-level developers quickly. Best paired with PostgreSQL only — multi-database portability is harder without an ORM's dialect abstraction.