Migrate from Mongoose
How to migrate to Mongster from Mongoose
Moving from Mongoose to Mongster is less about renaming APIs and more about simplifying the runtime model.
Mongoose gives you documents, middleware, virtuals, plugins, and a large model API built around Schema and mongoose.model(). Mongster keeps the collection-oriented parts and removes the document abstraction layer.
Concept mapping
| Mongoose | Mongster |
|---|---|
new Schema({...}) | M.schema({...}) |
mongoose.model("User", schema) | model("users", schema) or mongster.model("users", schema) |
schema.index({ a: 1 }) | schema.addIndex({ a: 1 }) |
{ timestamps: true } | .withTimestamps() |
Model.find().populate("author") | Model.find().populate("authorId") |
session.withTransaction(...) | mongster.transaction((ctx) => { const TxUser = ctx.use(User); ... }) |
A typical target shape
import { , } from "mongster";
const = .({
: .().(1),
: .().(),
: .(),
})
.({ : 1, : 1 }, { : true })
.();
const = ("users", );What usually changes in real code
- Replace document instance workflows like
doc.save()with explicit model calls such ascreateOne(),updateOne(), orfindOneAndUpdate(). - Replace schema paths and options with
M.*builders. - Replace relation fields with
M.objectId().ref(() => Model)when you want populate. - Move logic that depended on Mongoose virtuals or document methods into plain functions or service-layer code.
Hooks and middleware
Mongoose middleware often centers on document lifecycles like save. Mongster hooks are query and operation focused instead. In practice, that means you will usually rewrite middleware around collection operations such as createOne, updateOne, find, or one of the hook group aliases like save, modify, and remove.
Important fit check
If your application relies heavily on Mongoose plugins, discriminators, document methods, or virtuals, the migration is architectural. Mongster is intentionally smaller and more explicit.