Plot Twist: We're All Building the Same ORM

A few years ago, Drizzle ORM burst onto the scene with a compelling pitch: at "~7.4kb minified+gzipped," they positioned themselves as the anti-Prisma. No heavy Rust engine, no migration complexity, no abstractions hiding SQL. Just lightweight, typesafe SQL that stays close to the metal. And honestly? They had a point. The "just write SQL" philosophy is genuinely appealing, especially to developers who know databases well. We've been called "bloated," "over-engineered," and "too magical" enough times to appreciate why a fresh, minimal approach resonated with developers.

Fast forward to 2025. Drizzle's "Relational API v2" and their massive "Alternation Engine" PR #4439 tell a different story: 363 commits, 9,000+ tests, and systematic implementation of migrations, object-based queries, and abstractions. As someone who's been through that exact journey (we remember when our migration test suite exploded), we can say with authority: this is impressive, necessary engineering work. Here's what makes this fascinating: two ORMs with opposite starting philosophies, built by different teams, are converging on remarkably similar architectures. This isn't about who copied whom, it's about discovering what production applications actually need.

This post isn't about declaring winners. It's about what this convergence reveals: certain patterns aren't arbitrary preferences or framework opinions, they're optimal solutions that emerge when you tackle production-scale database problems. Whether you start lightweight or comprehensive, you end up in similar places. We think that's pretty cool. And we'd be lying if we said it doesn't feel validating.

The Migration Engine: Complexity Demands Specialized Attention

Let's talk about migrations. Drizzle has always had schema-first migrations and automated tooling and their commands for the same have been remarkably similar to Prisma's from day one. But their ongoing Alternation Engine work reveals something we learned the hard way back in 2021: building reliable migrations across databases isn't a weekend project. The test suite expansion alone tells the story. You don't go from 600 to 9,000+ tests because you're over-engineering. You do it because migrations are genuinely complex: edge cases across database vendors, tricky alterations (column renames, type changes), data preservation during schema evolution, and the intricacies of multi-dialect support.

Migration Commands: Parallel Evolution Validates Design

These commands have been remarkably similar from the start, and for good reason. When you're building production-grade migration tooling that needs introspection, code generation, schema diffing, and migration execution across multiple database vendors, you naturally arrive at similar command structures. Both teams independently discovered that push/pull for rapid prototyping and generate/migrate for production workflows isn't arbitrary, it's necessary. This parallel evolution proves these design patterns weren't over-engineering. They're what production migration systems require. We learned this through years of iteration. Drizzle is learning it now through their comprehensive rewrite. Same lessons, different timeline.

What The Rewrite Reveals

Here's what we love about the Alternation Engine work: it shows a team that's willing to rebuild when users need more. The scope: refining diffing, restructuring folders, adding CockroachDB and SQL Server support, is exactly what we went through with Prisma Migrate. It's not glamorous work, but it's essential work.

The 9,000 tests aren't just about completeness. They're proof that getting migrations right across databases is genuinely difficult. You can't hand wave edge cases. You can't ignore the intricacies of ALTER TABLE across vendors. Production usage exposes every corner case.

To be clear: Drizzle's SQL-first philosophy has genuine merit. For teams with deep SQL expertise who want maximum control, seeing exactly what SQL runs is valuable. Their lightweight TypeScript schema definitions eliminate a separate schema language. For simpler applications, their approach works great.

But when you scale to production complexity, need to coordinate schema changes across teams, maintaining reliability across environments, moving fast without breaking things, you end up building what they're building now: sophisticated diffing, extensive testing, robust tooling. The 9k tests aren't overkill. They're the cost of doing migrations right.

Relational Queries: The Complete Convergence

Okay, this is where it gets really interesting. Let's talk about relational queries. In their own Relational API v2 discussion, Drizzle's team acknowledged their original approach had "several major flaws" and concluded that object-based filters, the exact pattern their early positioning dismissed as unnecessary abstraction: "just feels natural."

We don't say this to gloat. We say it because watching another team arrive at the same conclusion through independent experience is genuinely validating. Let's look at the APIs side by side.

Fetching Related Data - Spot the Difference

The APIs are nearly identical:

Look at that. Nearly identical patterns. The differences are mostly naming: include vs with, select vs columns, take vs limit.

When we launched this API in 2020, people said we were over-abstracting SQL. "Just write joins!" they said. Now here we are, five years later, and the SQL-first ORM has implemented the same abstraction with slightly different names.

Here's the thing: we're not claiming they copied us (though we'd be flattered). We're claiming that when you build for production-scale relational queries, you naturally converge on these patterns. They feel natural because they work.

From Drizzle's v2 migration documentation, these features were "not supported in v1":

• Filtering by relations
• Using offset on nested relations
• Predefined filters in relation definitions
• Direct many-to-many queries (required manual junction table mapping)
• Object-based where and orderBy syntax

All of these have been core Prisma features since 2020. And all of them are what Drizzle users were asking for loud enough that the team rebuilt their entire relational query system.

Even more telling: Drizzle v2 deprecated their callback-based syntax entirely, moving it to db._query and import from 'drizzle-orm/_relations' while giving the clean db.query namespace to object-based patterns. That underscore prefix conventionally signals "internal," "deprecated," or "legacy" in JavaScript. The new default is object-based queries…exactly what Prisma pioneered.

Their v2 migration docs confirm: "where is now object" and "orderBy is now object." This isn't incremental improvement. It's a philosophical pivot driven by what users actually need.

Consider this example:

The readability difference is stark. The SQL requires LATERAL joins, JSON aggregation, nested subqueries, and careful correlation. One wrong alias or join condition and you're debugging for hours. The object-based version reads like a description of what you want. For simple queries? Sure, raw SQL is fine. But production applications need code you can reason about at 3am, debug without a PhD in SQL optimization, and onboard junior developers to understand quickly. This is why both ORMs converged here. The "close to SQL" approach works great for straightforward queries and individual projects. But production-level complexity with distributed teams demands higher-level patterns. Drizzle's users learned this. Their team listened. That's good product development.

Having to manually navigate junction tables and map results yourself isn't "close to SQL," it's just tedious. Drizzle v2 finally added first-class many-to-many support, the experience Prisma has always provided. Again: this isn't criticism. It's validation. The "just write SQL" approach inevitably needs abstraction layers when real users build real applications. We learned it in 2019. Drizzle learned it through user feedback. Same lesson.

Performance: Everyone's Getting Better

Here's where the story gets interesting, and honestly, kind of fun.

While Drizzle adds sophisticated features (migrations, relational queries, growing test coverage), Prisma went the opposite direction in terms of architecture: we removed our entire Rust engine, becoming 90% smaller and 3-4x faster in many scenarios.

Wait, smaller and more features? Yes. Turns out the complexity isn't in the feature set, it's in the architecture. We spent years building sophisticated query engines and migration tooling in Rust, only to discover we could achieve better results with optimized TypeScript. Sometimes you need to build the complex version first to learn what complexity you actually need.

Type-Checking Performance

There's another dimension worth discussing: developer experience during actual coding. Our comprehensive benchmarks with TypeScript expert David Blass reveal something interesting. Even Drizzle's own community raised concerns in their v2 discussion, noting that "Prisma has a codegen step to create the types which would help the approach scale."

Why? Prisma generates types at build time while Drizzle infers them on every keystroke:

The point isn't "we win, they lose." The point is that different architectural choices have real tradeoffs. Code generation adds a build step but delivers faster type-checking. Type inference is more immediate but can get expensive at scale. There's no free lunch, just different costs.

What We're All Learning

Step back and look at the pattern: two ORMs with opposite starting philosophies, built by different teams with different priorities, converging on remarkably similar architectures. This isn't random, it reveals fundamental truths about what production applications require.

What Production Demands:

1. Migrations need specialized attention: The 9k test suite isn't overkill, it's the cost of reliability across databases
2. Object-based queries win for complex relations: Eventually everyone needs include/with patterns
3. Relations need first-class support: Manual junction table navigation doesn't scale to real teams
4. Type generation beats inference at scale: Better performance, better DX for large schemas
5. Features aren't bloat: They're answers to problems users actually have

What This Teaches About Building Tools:

1. Starting philosophy doesn't determine ending architecture: You can start minimal or comprehensive because production requirements force convergence
2. Users reveal what's necessary: Features you think are optional become essential when people build real things
3. Performance comes from architecture, not slogans: "Lightweight" and "fast" are outcomes of good engineering, not marketing positions
4. Flexibility beats ideology: Being willing to rebuild when users need more is better than rigidly defending original choices

These patterns aren't "Prisma patterns," they're patterns that emerge when solving production database problems. We got here first. We'd argue our path was more direct. But the destination is the same.

Meanwhile, at Prisma

While the ecosystem converges on similar ORM patterns, we've been pushing in a different direction entirely.

The Rust-to-TypeScript migration shows our commitment to developer experience over dogma. We built sophisticated Rust engines, learned what complexity we actually needed, then rebuilt in a way that's smaller and faster. That's optimization, and we're proud of it.

But the real innovation? Prisma Postgres: a database designed from the ground up to work seamlessly with Prisma ORM. We're not just building an ORM anymore, we're creating an integrated data platform where the database and ORM speak the same language.

This is the kind of innovation that happens when you're not busy rebuilding features you once claimed weren't needed. (Okay, okay, that was a little spicy. But seriously, we're excited about where this is going.) And here's the thing: we genuinely want other ORMs work great with Prisma Postgres too. Rising tide lifts all boats. More good ORMs means more developers building with databases, which means more potential Prisma Postgres users. Everyone wins.

Looking Forward: Why Convergence Matters

The evolution from Drizzle v1 to v2 isn't just feature additions, it's a philosophical pivot validated through production experience. They deprecated callback-based queries, moved them to underscore-prefixed APIs, and gave the clean namespace to Prisma-like patterns. Their docs repeatedly note features that were "not supported in v1" but are now core to v2.

We're flattered. We're validated. And honestly? We're impressed. Building a comprehensive relational query system and migration engine is genuinely hard work. The Drizzle team is doing it well.

Here's what this convergence means for developers: When ORMs converge on patterns, onboarding gets easier, switching gets smoother, and the ecosystem gets more coherent. If you know Prisma's query patterns, you'll feel at home in Drizzle v2. If you know Drizzle's schema definitions, Prisma's won't feel alien. That's good for everyone.

Not every application needs all of this. If you're building a simple API with straightforward data models, or if your team has deep database expertise and prefers seeing explicit SQL, lighter-weight tools work fine. The convergence we're discussing happens primarily at production scale: multiple environments, team coordination, complex data relationships, varied skill levels across developers.

For teams evaluating ORMs today, the question isn't "lightweight vs. heavy" anymore. Both tools are converging on the same features because those features solve real problems. The question is: do you want battle-tested implementations available today with Prisma ORM v6, or do you want to adopt tools that are still implementing patterns we've been refining for years?

We think we know the answer, but we're biased.

To the Drizzle team: Seriously impressive work on v2. The engineering effort is clear, the community response is strong, and the architectural convergence validates what we've both learned about production database tools. We'll be watching with interest (and maybe borrowing good ideas right back). See you at the convergence point.

To everyone else: May the best API win. Or you know, may we all just build really good tools that make developers' lives easier. That works too.

Ready to migrate to the latest Prisma ORM? Check our comprehensive guide.