Daniel sent us this one — he wants to talk about ORMs in data application design. Not the surface-level "which one's popular" conversation, but the real question: which ORM gives you the most seamless path toward building an AI-native backend and an MCP server, with the fewest headaches when your schema inevitably changes. He's asking us to compare across SQL, Postgres, MongoDB, and graph databases, with a bias toward what's most AI-native.
Before we dive in — quick note, DeepSeek V four Pro is writing our script today. There, that's out of the way. I've been watching this space closely, and honestly, the conversation has shifted more in the last eighteen months than in the previous decade.
That's a strong claim.
Two things happened at once. First, the TypeScript ecosystem consolidated around two clear winners for new projects — Drizzle and Prisma. TypeORM is still out there, but it's legacy at this point. But the second shift is bigger — ORMs are being designed for AI agents, not just human developers.
What does it mean for an ORM to be designed for an AI agent?
Think about what an AI code assistant needs. It needs predictable, well-documented APIs that map directly to concepts it's been trained on. It needs fast feedback loops — compile-time errors instead of runtime surprises. And ideally, it needs machine-readable error codes that an agent can parse and act on without a human translating. Prisma's team announced something called Prisma Next in March — that's the forthcoming Prisma eight — and they explicitly said they're building for "agent-centric development." Machine-readable error codes, middleware that acts like ESLint for your database, compile-time guardrails that block dangerous patterns before they ship.
The ORM becomes a safety layer between an AI-generated query and your production database.
It's more than interesting — it's a fundamental rethinking of who the user is. The Prisma team is betting that the primary consumer of ORM error messages in a few years won't be a person reading a stack trace. It'll be an AI agent that needs structured feedback to correct itself.
Which raises a question Daniel's prompt gets at indirectly — if AI is going to generate most of our queries, do we even need an ORM? Couldn't we just have the AI write raw SQL?
This is the misconception that keeps coming up. People think ORMs are just about avoiding SQL. They're not — not the good ones, anyway. A modern ORM is a schema compiler. It takes your data model definition and generates types, migrations, and query builders that are guaranteed to be consistent with each other. Raw SQL gives you none of that. You can change a column name in a migration file, and your TypeScript types update automatically. You can't get that with hand-written SQL unless you're also maintaining type definitions manually, which nobody does consistently.
The AI angle actually makes this more important, not less. If an LLM generates a migration for you, you want the ORM's type system to catch mismatches immediately.
The ORM becomes the verification layer. And this is where the choice between Drizzle and Prisma gets genuinely interesting, because they have completely different philosophies.
Let's frame that difference before we go deeper.
Drizzle is what I'd call SQL-proximate. Its API is essentially SQL syntax expressed in TypeScript. If you know how to write a SELECT with a JOIN in SQL, you'll recognize the Drizzle equivalent immediately. There's no generation step — you define your schema in TypeScript, and the types exist instantly. The bundle size is about seven point four kilobytes minified and gzipped.
Prisma is schema-first. You define your data model in a declarative language — the dot-prisma file — and then Prisma generates a type-safe client from that definition. Historically, this meant a Rust-based query engine adding about fourteen megabytes to your bundle. But Prisma seven, which shipped in late twenty twenty-five, removed the Rust engine entirely, making the client pure TypeScript. Bundle size dropped to about one point six megabytes — still larger than Drizzle, but a ninety percent reduction. Cold starts in serverless environments got dramatically faster.
Prisma closed the gap on performance, but the philosophical difference remains.
And that philosophical difference is really about who the ORM is for. Drizzle rewards developers who already know SQL and want transparency — you can see exactly what query will be generated because the API maps directly to SQL constructs. Prisma abstracts SQL away, which lowers the barrier for teams where not everyone is comfortable writing complex queries.
I want to push on the AI-native question, because Daniel flagged it as his primary criterion. Which one actually works better with tools like Copilot and Cursor?
There's a nuanced answer here that I think most coverage misses. Drizzle wins on raw AI-friendliness for code generation, because its SQL-like API is exactly what LLMs have been trained on. An AI tool can generate a correct Drizzle query with less hallucination risk because the API mirrors SQL concepts directly. But Prisma Next is being designed to be the better platform for AI agents in the long run — not for generating code, but for verifying it. The compile-time guardrails, the structured error codes, the middleware that blocks dangerous patterns — that's all infrastructure for a world where AI writes the code and the ORM validates it.
Drizzle is easier for AI to write, but Prisma is building better guardrails for catching AI mistakes.
That's exactly the tradeoff. And it's not obvious which one matters more yet. If your AI-generated code is correct ninety-five percent of the time, do you optimize for making generation easier, or for catching the five percent of errors before they hit production?
The answer probably depends on what you're building. A startup moving fast might prefer Drizzle's simplicity. A team with compliance requirements might want Prisma's guardrails.
This is before we even get into the multi-database question, which is where things get really interesting. Prisma seven shipped without MongoDB support because removing the Rust engine made it harder than they anticipated. MongoDB support is now slated for Prisma Next. Drizzle has had MongoDB support longer, but there's a deeper issue here — document databases don't fit the relational ORM model well at all.
Let's save that for when we dig into MongoDB specifically. I want to stay on the core comparison, because there's one more thing Daniel's prompt raises — migrations.
This is where I get excited, because migration design is the part most teams get wrong. Both Drizzle and Prisma handle migrations, but the approaches are different. Drizzle generates numbered SQL migration files with a journal manifest. Prisma's migration engine — even after the Rust removal in Prisma seven — still uses a declarative approach where you define the desired schema state and it computes the diff. And neither one supports rollbacks.
Neither one supports rollbacks.
This is intentional — both teams consider built-in rollback support an anti-pattern. The argument is that forward-fixing with a new migration is always safer than trying to reverse a migration that may have already run against production data. But this assumes you have a CI/CD pipeline with staging environments.
Which is not always true.
I read a fascinating survey from Ardent Performance Computing just last month — they looked at migration practices across more than forty major open-source projects, including GitLab, WordPress, Kubernetes, and Firefox. Desktop applications — think Firefox, Chromium, Signal Desktop — they run sequential version chains on startup with no rollback capability, across hundreds of millions of installations. No DBA watching, no rollback possible, and users who might skip many versions between upgrades.
That's a completely different migration reality from a cloud SaaS with a staging environment and a database administrator on call.
And the survey's main finding was that the framework provided by your programming language is the most common migration pattern — not standalone tools like Flyway or Liquibase. The application process itself triggers schema migration in most projects. Which means your ORM choice is also your migration strategy choice.
What does that mean practically? If I'm building a new project today and I pick Drizzle, what's my migration workflow?
You define your schema in TypeScript. When you want to change it, you modify the schema file, run drizzle-kit generate, and it produces a numbered SQL file with the ALTER TABLE statements. You review that SQL — this is important, you always review generated migrations — and then you apply it. Drizzle has a strict mode that's critical for catching ambiguous changes. If you rename a column, Drizzle in normal mode might interpret that as "drop the old column, add a new one," which would lose your data. Strict mode forces you to be explicit about renames.
You modify the schema dot-prisma file, run prisma migrate dev, and Prisma computes the difference between your desired schema and the current database state. It generates the migration SQL automatically. The generated code now lives in your source directory rather than node modules, which is a Prisma seven change that makes it easier to review and version control.
One thing I've noticed is that the data model is the hardest thing to change later in a project. Frontend you can refactor. API endpoints you can version. But your database schema, once it has production data in it, every change is a surgery.
Which is why the schema-first versus code-first debate matters so much. Prisma's declarative schema forces you to think about your data model as a separate artifact from your application code. Drizzle lets you define it in TypeScript alongside your business logic. Neither is wrong, but they encourage different habits.
I lean toward treating the schema as a first-class artifact that deserves its own file and its own review process. But I also understand why teams like having everything in TypeScript — one language, one toolchain, less context switching.
This is where the AI-native question circles back. If you're using an LLM to help design your schema, the schema-as-separate-artifact approach has an advantage. You can feed the entire dot-prisma file to an AI and say "review this for issues" without it getting lost in application logic. But Drizzle's TypeScript-native approach means the AI can see how your schema connects to your query patterns in the same context window.
There's no clean winner here. It depends on your workflow.
Which is honestly the right answer for most engineering decisions. But I do think there's a clear recommendation emerging for the specific use case Daniel is asking about — AI-native backend with MCP server integration. And that recommendation is Drizzle, with a caveat.
Let's hear the caveat.
Drizzle gives you the cleanest path to generating MCP-compatible backends because its schema definitions are just TypeScript objects — you can introspect them at build time, generate MCP tool definitions automatically, and the SQL-like API means your MCP server's queries will be predictable. There's even a tool called drizzle-mcp emerging in the ecosystem. But the caveat is Prisma Next. If Prisma delivers on its agent-centric vision — the machine-readable error codes, the compile-time guardrails, the plugin system — it could become the better platform for AI-native development within a year or two.
The recommendation is Drizzle now, but keep an eye on Prisma Next.
For most new projects, yes. Especially if you're building something that needs to integrate with AI tooling today. Drizzle's simplicity is a feature here — fewer abstractions means fewer places for AI-generated code to go wrong. For teams already on Prisma, stay on Prisma. The migration to Prisma seven already improved performance significantly, and Prisma Next will be an evolution, not a rewrite. The real question is for teams starting fresh, and for them, I think the answer is Drizzle unless they have a specific reason to choose Prisma — like a frontend-heavy team that really benefits from Prisma's abstraction layer.
That's a fair framework. And we haven't even touched MongoDB and graph databases yet, which is where this gets messier.
The ORM landscape for non-relational databases is still immature, and there's a fundamental impedance mismatch between document models and relational ORM patterns.
Let's pick that up next. I want to dig into why MongoDB and ORMs have such a complicated relationship, and what you should actually use if you're building on a document store or a graph database.
We should talk about the MCP server generation piece specifically, because that's where the ORM choice has downstream effects that most teams don't think about until they're deep into implementation.
Before we go there — you mentioned Drizzle's bundle size. What's the actual performance difference on real queries?
The benchmarks I've seen show Drizzle leading on raw query execution — around twelve milliseconds for a thousand-row bulk insert versus about forty-five milliseconds for Prisma. But for typical web application queries, the difference is one to three milliseconds per query. That's negligible compared to network latency. The meaningful performance difference is in cold starts — serverless functions, edge runtimes, anywhere you're paying a penalty for initialization. Drizzle's tiny bundle means near-instant cold starts. Prisma seven closed that gap significantly, but Drizzle still has the edge.
For most applications, the performance argument is a tie, and the decision comes down to developer experience and AI-tooling compatibility.
ORMs are becoming schema compilers and type-safety layers more than query optimizers. The database itself is already good at optimizing queries. What the ORM adds is correctness guarantees — catching your mistakes before they reach production, and working predictably with your AI tools. That's the new constraint that didn't exist five years ago, and it's reshaping the entire category.
Which brings us back to the deeper question underneath Daniel's prompt. What is an ORM actually doing for you now that it didn't do ten years ago?
The old pitch was basically "you don't have to write SQL." That hasn't aged well. The value of a modern ORM in twenty twenty-six is really three things. Schema definition as a single source of truth. Type-safe migrations that you can version control and review. And type generation that flows through your entire application stack — your API layer, your frontend, your MCP server, all of it knows the shape of your data.
It's less about hiding SQL and more about guaranteeing correctness.
And the "why can't we just write SQL" question has a real answer now. You can write SQL. Tools like Kysely give you type-safe SQL without an ORM. But what you don't get is a migration framework, or schema introspection that generates types automatically, or a single artifact that defines what your database is supposed to look like.
The AI angle changes this too. If I'm having an LLM generate queries against my database, I want those queries to be validated against a schema before they execute. Raw SQL from an AI is terrifying — I've seen LLMs hallucinate column names, invent join conditions, drop indexes they shouldn't touch. The ORM becomes the thing that says "that column doesn't exist" before the query ever reaches Postgres.
Which is the schema-first argument in a nutshell. But here's the tension. Schema-first tools like Prisma give you that safety at the cost of abstraction — you're defining your model in a DSL that isn't TypeScript, and there's a generation step between you and your types. Code-first tools like Drizzle give you direct expressiveness — your schema is TypeScript, your types update instantly on file save — but you have to be more disciplined about keeping your schema and your queries consistent.
It's the classic tradeoff between flexibility and guardrails. And the guardrails matter more the larger your team gets. A solo developer can hold the whole schema in their head. A team of twenty engineers needs something that catches mistakes automatically.
Which is why Prisma's compile-time guardrails in Prisma Next are so interesting. The middleware that blocks deletes without a WHERE clause — that's not for the developer who knows what they're doing. It's for the developer who's tired at four PM on a Friday. Let me walk through a concrete scenario. Say you need to add a NOT NULL column to an existing users table that already has production data.
The classic "we forgot to track timezone" moment.
In Drizzle, you define the new column in your TypeScript schema file, then run drizzle-kit generate. It produces a numbered SQL migration file. But if you just add a NOT NULL column, the generated migration will fail when it runs against existing rows. Drizzle doesn't try to be clever — it generates exactly the ALTER TABLE statement you asked for, and it's on you to handle the data migration. You'd edit the generated SQL to add a DEFAULT clause, or write a separate data migration script. Drizzle gives you raw SQL files that you control completely. The tradeoff is you have to understand what you're doing.
Prisma's migrate dev command detects that you're adding a required column and will prompt you interactively — "this column is required, what value should existing rows get?" It bakes that into the migration automatically. More guardrails, less manual SQL editing. But also less transparency into what exactly is happening.
Prisma is protecting the Friday afternoon developer, and Drizzle is trusting the developer who knows exactly what ALTER TABLE does. Both approaches have failure modes. Drizzle's strict mode is essential — if you rename a column without it, you might lose data. Prisma catches this by never inferring destructive changes — it won't drop a column unless you explicitly mark it as a breaking change.
This connects to the AI-native question directly. When you're generating migrations with AI assistance, the ORM's migration strategy determines how reviewable the output is. Drizzle's numbered SQL files are dead simple for an AI to generate and for a human to review. Prisma's generated migrations are more abstracted, which means the AI has to understand Prisma's migration DSL, not just SQL. For now, Drizzle wins on simplicity for AI-generated migrations. But Prisma Next is introducing migration graphs — branching migration histories instead of linear files — which could actually be better for AI agents that need to reason about schema evolution across multiple branches and environments.
That's either the future or a disaster waiting to happen.
It depends on the guardrails. The idea isn't "let AI manage your database unsupervised." It's "give the AI fast feedback loops so it catches its own mistakes before a human even sees the pull request.
Which brings us to TypeORM and MikroORM. Where do they fit into this AI-native picture?
They don't, really. TypeORM's decorator-based approach predates modern TypeScript type inference. The type generation is less reliable, and the migration system requires more manual intervention. For AI tooling compatibility, decorators are a problem — LLMs have less training data on TypeORM-specific patterns, and the schema definition is scattered across entity files rather than centralized. MikroORM is more modern — it supports both decorator and schema-first approaches, and its migration system is solid. But it hasn't seen the same ecosystem investment around AI tooling. There's no equivalent of drizzle-mcp for MikroORM. If you're building an AI-native backend today, you'd be fighting the ecosystem rather than flowing with it.
The AI-native criterion isn't just about whether an LLM can generate correct queries. It's about whether the entire toolchain — schema definition, migration generation, type inference, MCP server integration — is designed with AI-assisted development in mind. That's a higher bar than most ORMs clear.
Drizzle clears it because of its simplicity — SQL-like API, TypeScript-native schema, minimal abstractions. Prisma Next is explicitly aiming to clear it with agent-centric design. TypeORM and MikroORM weren't designed for this world, and it shows. The machine consumer has different needs — structured, parseable output, error codes it can act on programmatically, the schema definition in a single, self-contained artifact. Those are design decisions that have to be made early — you can't bolt them on later.
Which is why Prisma Next's bet on agent-centric design is so interesting. They're not just adding AI features. They're rethinking the ORM's architecture around the assumption that an AI agent will be in the loop.
That's either prescient or premature. We'll know in about two years.
We've covered the relational world pretty thoroughly, but Daniel's question pushes us further. What about databases that don't fit the relational mold at all? MongoDB, Neo4j, graph databases. This is where the ORM conversation gets messy.
Because the entire concept of object-relational mapping assumes you're mapping to something relational.
And MongoDB isn't relational. It's a document store. The data model is nested documents and arrays, not tables and foreign keys. When you try to force an ORM designed for relational databases onto MongoDB, you get an impedance mismatch — the tool is fighting the data model rather than working with it.
What does that actually look like in practice?
Take a simple example. In Postgres with Drizzle, if you have users and posts, you define a users table, a posts table, and a foreign key from posts dot user id to users dot id. The relationship lives in the schema. In MongoDB, the natural way to model that is embedding posts as an array inside the user document, or storing user id as a field on each post document with no enforced foreign key. The ORM's relational abstractions — joins, cascading deletes, referential integrity — don't translate cleanly.
Yet Prisma has a MongoDB connector.
Had one in Prisma six, lost it in Prisma seven when they removed the Rust engine, and it's coming back in Prisma Next. The way it works is by papering over the differences — you define a Prisma schema that looks relational, and the connector translates it into MongoDB operations. For simple lookups, it works fine. But as soon as you need aggregation pipelines, embedded document queries, or anything that's idiomatic MongoDB, the abstraction breaks down and you're fighting the ORM.
The answer to "should you use an ORM with MongoDB" is...
For most projects, no. Mongoose gives you schema validation and a query API that actually respects MongoDB's document model. It's an ODM, an object-document mapper, and that distinction matters. If you need a unified tool across Postgres and MongoDB, MikroORM supports both, but you'll write different query patterns for each. The unified API is surface-level.
What about graph databases? Daniel mentioned those specifically.
This is even more stark. There is no mature ORM for Neo4j in the TypeScript ecosystem. The Neo4j JavaScript driver has over a million weekly npm downloads as of early twenty twenty-six, and that's what people use — a raw driver with Cypher queries. Graph databases model data as nodes and edges with properties, which is fundamentally different from tables and rows. An ORM designed for relational databases simply can't represent graph traversals, variable-length paths, or graph algorithms in a natural way.
You're writing raw Cypher queries.
Or you put a GraphQL layer on top. GraphQL's type system maps surprisingly well to graph database schemas — your resolvers become graph traversals. There are tools like Neo4j GraphQL Library that generate a GraphQL API directly from your type definitions, including full CRUD operations and support for the at directive authentication. It's not an ORM, but it solves the same problem: type-safe data access without writing raw queries.
That connects directly to the MCP server question. If you're building an MCP server that exposes your database to AI agents, the cleanest path depends heavily on your ORM choice.
This is where Drizzle really shines. Better Auth — which is the authentication layer the Builder dot io React and AI stack for twenty twenty-six specifically recommends — ships with an official Drizzle adapter and an MCP server. You run npx at better hyphen auth slash cli at latest generate, it reads your Drizzle schema, and it produces an MCP-compatible backend with authentication baked in. The AI agent can then interact with your database through the MCP protocol without hallucinating API endpoints.
Because the schema is the source of truth, and the MCP server is generated from it.
Drizzle's TypeScript-native schema definition means there's no intermediate DSL to parse — tools can import your schema directly as a TypeScript module and reason about it programmatically. Prisma requires parsing the dot prisma file first, which is doable but adds a step. And for MongoDB or Neo4j, you'd likely be building a custom MCP server that wraps the native driver — there's no off-the-shelf "Mongoose to MCP" generator.
The ORM choice cascades into your MCP architecture. Pick Drizzle for Postgres, and you've got a clear path to an MCP server with auth. Pick Prisma, and you're waiting for Prisma Next's agent-centric tooling to mature. Pick MongoDB or Neo4j, and you're building more of the integration yourself.
That's really the through-line of this whole conversation. The ORM isn't just about how you query your database anymore. It's about what kind of ecosystem you're buying into — AI tooling, MCP servers, type generation, migration safety. The database choice and the ORM choice are increasingly one decision. For now, the ecosystem is overwhelmingly built around relational databases with Drizzle or Prisma as the ORM layer. Everything else is catch-up.
Given all of that, what do you actually tell someone starting a new project tomorrow? What's the decision framework?
For most new projects in twenty twenty-six, I'd point them to Drizzle. It gives you the best balance of type safety, migration flexibility, and AI-tooling compatibility. The seven point four kilobyte bundle size means it works everywhere — edge functions, serverless, whatever. The SQL-like API means AI assistants generate correct queries with minimal hallucination. And the TypeScript-native schema means tools like Better Auth can import your schema directly and generate an MCP server from it.
When would you not pick Drizzle?
If your team isn't comfortable with SQL, or you want the richest documentation and tooling ecosystem, Prisma is still the better choice — especially for rapid prototyping where you want to iterate on the schema quickly without thinking about migration SQL files. Prisma Studio gives you a visual database browser, the declarative schema is easier for frontend-heavy teams to read, and Prisma Next's agent-centric features could be transformative once they ship. But you're betting on something that hasn't shipped yet. Drizzle gives you certainty today. Prisma Next is a bet on where the ecosystem is heading.
When do you skip ORMs entirely?
One, graph databases. Neo4j, Dgraph — there's no mature TypeScript ORM, and the relational model simply doesn't map. Use the native driver with Cypher, or put a GraphQL layer on top with the Neo4j GraphQL Library. Two, high-throughput document stores where you're doing heavy aggregation pipelines or embedded document queries. Mongoose gives you schema validation without the relational abstraction overhead. Trying to force Prisma or TypeORM onto MongoDB is fighting the data model.
The decision tree is: relational database with Drizzle or Prisma, document store with Mongoose, graph database with native drivers or GraphQL. And the ORM choice is really about which ecosystem you're joining.
That's the future-proofing point. Pick an ORM that supports your target database and has an active community around AI-native tooling. Right now, Drizzle and Prisma are the only two that clear both bars for relational databases. Everything else is either legacy or niche. And if you're building something that'll need to integrate with AI agents — whether through MCP servers or direct code generation — the ORM you choose today determines how much of that integration you get for free versus having to build it yourself.
Here's the question I keep coming back to. If AI gets good enough at generating raw SQL — and we're already seeing it produce correct queries most of the time — does the ORM eventually become obsolete? Are we just building training wheels?
I think that's the wrong framing. The ORM's value is shifting, not disappearing. When AI generates raw SQL, you still need something that validates that SQL against your schema before it hits production. You need type generation so your application code stays in sync. You need migration management. The ORM becomes less of a query builder and more of a schema compiler — it takes your data model definition and produces the artifacts the AI and your application both consume.
The ORM moves from runtime to compile time.
That's exactly where Prisma Next is pointing. The runtime query layer becomes thinner, but the schema-as-source-of-truth becomes more important. If an AI agent proposes a schema change, you want a compiler that can verify it, generate the migration, check for data loss, and produce the updated types — all before any code reaches your database.
Which means the ORM of the future might not even look like an ORM as we know it today. It's a schema compiler with AI-readable outputs and safety guardrails baked in.
That's why this conversation matters now. The choices you make in twenty twenty-six about Drizzle versus Prisma aren't just about query ergonomics. You're picking which compiler architecture you're betting on for the next five years of AI-native development.
One of those thoughts that makes you want to go take a very long nap.
Now: Hilbert's daily fun fact.
The collective noun for a group of sloths is a "bed.
If you're starting a project and this episode helped you think through the ORM decision, we'd love to hear what you picked and why. Drop us a review wherever you listen, or find us at myweirdprompts dot com. This has been My Weird Prompts, produced by the one and only Hilbert Flumingtop. I'm Herman Poppleberry.
I'm Corn. Go define your schema before the AI does it for you.
