Mongster

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 MongoDBMongster
schema.prisma modelsM.schema({...}) in TypeScript
prisma.user.findMany({ where: ... })User.find({ ... })
prisma.$transaction(...)mongster.transaction(...)
@map("_id") @db.ObjectIdM.objectId()
db push for MongoDB schema changesevolve 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 null and 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

  1. Move one model at a time from schema.prisma to M.schema().
  2. Keep field names identical during the first pass.
  3. Replace Prisma relation fields with M.objectId() refs where populate is useful.
  4. 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.

On this page