This boundary is controlled by React's Server Components serializer, not MongoDB or Next.js. React supports only a fixed set of types with no way for libraries to register custom ones, so ObjectId can't cross natively. That'd be a React feature request (already raised and declined in react/react/issues/25687).

That being said, the pain you describe is real and it would be nice to have easier ObjectId handling like in other ecosystems. Would you mind sharing how you're currently mapping data? and how would you ideally want it to work if it were a Mongo-side solution?

Thanks, but I still have to write wrapper code for each and every object just to handle _ids. I feel like I'm fighting mongodb, and I love Mongodb, it's frustrating.

I ended up saving _id's as ULIDs instead of ObjectIds. But again it'd be nice if MongoDB played nicer with modern web frameworks and had native serialization so I don't need to write all this boilerplate code. I assume this could be a minor driver as to why people switch to prism/postgres on next.js, tbh I almost switched.

Thanks for the feedback. You don't need to write per‑model mappers. You have two ready‑made options:

• JSON.stringify/JSON.parse (simplest). It's built‑in in JS, flattens every ObjectId to a string.

• EJSON.serialize/EJSON.deserialize (recommended for mongo-specific data). From the bson package we ship, it's a generic mapper, similar to JSON.stringify, that preserves Mongo‑specific types (ObjectId, Decimal128, Long, dates, etc.). This turns ObjectId into a plain object (not a string though)

Let us know if this helps your use case.