Migrations
Migrate from Prisma
Move from Prisma's MongoDB workflow to TypeScript-native MongoDB models
Prisma and Mongster solve different problems.
Prisma gives you a generated client from a separate schema.prisma file. With MongoDB, that means you model _id with @map("_id"), use @db.ObjectId, generate a client, and push schema changes with db push because Prisma Migrate is not supported for MongoDB.
Mongster keeps everything in TypeScript and stays closer to MongoDB itself.
Concept mapping
| Prisma MongoDB | Mongster |
|---|---|
schema.prisma models | M.schema({...}) in TypeScript |
prisma.user.findMany({ where: ... }) | User.find({ ... }) |
prisma.$transaction(...) | mongster.transaction(...) |
@map("_id") @db.ObjectId | M.objectId() |
db push for MongoDB schema changes | evolve the schema in TypeScript and manage data migration directly |
A typical target shape
import { , } from "mongster";
const = .({
: .().(),
: .().(),
: .().(["ADMIN", "MEMBER"]).("MEMBER"),
}).();
const = ("users", );What changes in application code
- Queries become MongoDB-shaped again, including update operators.
- Relations become explicit ref fields instead of Prisma relation declarations.
- The distinction between
nulland missing MongoDB fields stays visible instead of being flattened by a generated client layer. - You stop depending on a code generation step for every schema change.
Migration advice
- Move one model at a time from
schema.prismatoM.schema(). - Keep field names identical during the first pass.
- Replace Prisma relation fields with
M.objectId()refs where populate is useful. - Revisit places where Prisma nested writes used transactions automatically. Mongster can do the same work, but you express the transaction boundary yourself.
Replica set note
Prisma's MongoDB connector requires a replica set for transaction-backed nested writes. Mongster has the same underlying MongoDB requirement for explicit transactions.