Prisma and MongoDB teams have collaborated to build Prisma Next — the first ODM to truly bring MongoDB's native experience into TypeScript.
This is the story of a TypeScript developer on their first day with MongoDB. This is you.
You fetch your first document
The very first time you try MongoDB, you connect, query, get a result, and then use it.
You know that your User documents have a name and a bio, but TypeScript sees them as any. Your editor can’t offer you autocomplete or tell you when you made a mistake.
So you diligently define type User { ... } by hand. Then Post, then Comment, one per collection. Types that go stale the moment your colleague writes a new field to the database.
Strike one.
You run an aggregation
You've heard how powerful MongoDB's aggregation pipeline is, and you want to try it out. It's one of the few query languages in any database where you can group, project, look up, and facet across documents in a single composable expression.
Expectations run high as you start chaining stages.
Every stage transforms the document's shape. There are no types at any stage, and by the end, you can't quite remember what the result was supposed to look like. To solve this, you start sprinkling console.log() throughout your code to identify the intermediate shapes. By casting the final result by hand, you hope the stages actually produce it. You’re taking a massive risk, though.
That’s strike two.
You add an index
You profile a slow query and decide you need an index. You reach for a migration tool — and there isn't one.
So you open a shell.
You put that line in a deploy script. You add a check at the top of your app that creates the index if it isn't there, in case the deploy script doesn't run. Or — and we won't tell anyone — you fire up mongosh and connect to production from your laptop, paste the line in, and call it done. (Production keys, on your laptop. Sssh.)
The index is the most common piece of database metadata you'll ever set up. You'll create dozens of them over a project's lifetime. And the way to do it is a js file you remember to copy somewhere, and hope.
Strike three.
Enter Prisma Next
Prisma Next is the missing TypeScript companion to MongoDB. It keeps track of the shape of every document in your database and uses that to give you type-safe queries, typed aggregation pipelines, and real migrations — designed from the start with documents, embedded data, polymorphic collections, and migrations as first-class.
Here's what each of those three scenarios looks like when you use Prisma Next with MongoDB.
One contract, types all the way down
Your document shapes live in one place — the Prisma contract — and types flow from there through every query.
Here's a contract for a sample app: users with embedded addresses, posts with indexes, and articles and tutorials as polymorphic variants of a single posts collection.
(It's a bit unfamiliar, but bear with me, everything else in the article flows from this contract)
From the contract above, Prisma Next applies strict type-checking to reads and writes end-to-end:
No handwritten type User. No drift. The contract is the only source of truth, and the compiler holds you to it — required fields on creates, field names in where clauses, the shape of every result document.
Relationships, both kinds
MongoDB has two complementary patterns for related data:
Embed for what you read together
Reference and $lookup for what you compose at query time.
Both are idiomatic. Both are typed.
Take Address as an example of embedding in action. Rather than storing addresses in a separate collection and joining them later, Address is declared as its own type and nested directly inside User as a typed field. This means no extra collection to manage and no manual lookup to write.
The type safety reflects the shape of the data: address is optional on User, but when it is present, country is required. That's why alice.address?.country resolves to string | undefined — the optional chaining (?.) handles the case where address doesn't exist, and if it does, country is guaranteed to be a string.
For data you compose at query time, the contract declares a relation — Post → User via @relation(fields: [authorId], references: [id]) — and you opt in with .include():
Skip the .include() if the author isn't fetched or isn't in the type. There's no recentPosts[0].author?.name to defensively guard against, because author simply isn't there. Under the hood, .include('author') compiles to a $lookup stage — exactly the MongoDB feature you'd reach for by hand. The contribution is in the type system: include and result type are the same decision.
Polymorphic collections
One of the unique features of MongoDB is its ability to store related yet distinct documents within a single collection—such as articles, tutorials, various product types, and versioned documents. This capability was highlighted by their Driver team as the top missing feature in earlier versions of Prisma ORM.
The @@discriminator(kind) on Post and the @@base(Post, "article") on Article and Tutorial declare exactly that idiom. Prisma Next maps it to discriminated unions in TypeScript. Query all posts and you get the full union; query a variant, and the type narrows:
Standard TypeScript narrowing works on the union, exactly the way you'd write it by hand:
Single-collection polymorphism is one of MongoDB's superpowers, and it's where TypeScript tooling has been weakest.
The aggregation pipeline, typed end-to-end
We're continuing from the same leaderboard as strike two — highlighting the top authors based on their post count, along with the date of their most recent post and the corresponding author document attached — all written against Prisma Next.
f.authorId and f.createdAt aren't strings — they are typed field references against the posts collection. Misspell one, and you find out in the editor, before the query runs. Each step composes with awareness of its input and output types — .group() reads a Post and produces a new shape; .lookup() adds author: User[] to it. The result type carries through to the end. No console.log archaeology. No intermediate-shape interface blocks. No any between steps.
See Prisma Next in action:
When the typed builder doesn't cover what you need, you drop to raw MongoDB commands. Full control, no guardrails — the right shape for an escape hatch. Three tiers: the ORM for most queries, the typed pipeline builder for aggregation, and raw commands when you need them. The pipeline is yours; Prisma Next just types it.
Real migrations for MongoDB
The @@index declarations on Post are essential contract elements, as are the field types and their required status. They act as JSON Schema validators for the collection. Options such as time-series and capped collections also form part of this contract. If you alter the contract, simply run the planner to create the corresponding migration.
When you add an index, the planner emits a createIndex. If you set a field as required, the validator updates with it. If you switch a collection to a time series, the planner emits the correct collMod. Pre-checks, post-checks, full history, branching, and rollback — the same graph-based migration system that handles the SQL side, is applied to MongoDB's server-side state.
No more js files in your deploy script, no more mongosh in production, no more typing your prod keys on your laptop. (Sssh.)
Data transformations are seamlessly integrated into the same system, where TypeScript code undergoes type checking against a snapshot of the contract taken at the time the migration was created.
MongoDB, like any SQL database, has a tangible database state that requires careful management. This includes aspects such as indexes, validators, and collection options that need attention and oversight. But until now, ODMs have left MongoDB developers out in the cold, forcing them to manage it manually.
Prisma Next is the first ODM to close the loop: a real migration system that treats every production change like the high-stakes deployment it is.
Try it out
Prisma Next is in early access now, and you can try it today by running npx prisma-next init.
Open the contract, change a field, run prisma-next migration plan, see what happens — it takes about as long as reading this paragraph.
If you find any rough edges or something you were hoping for that's missing, drop into #prisma-next on Discord and tell us. Feedback from MongoDB developers right now is the most valuable thing we can get.
Or check out the prisma-next repo, star it, and watch it to follow updates as they land.