Skip to content

feat(db-mongodb): allow custom id field types#15522

Open
MurzNN wants to merge 1 commit into
payloadcms:mainfrom
Murz-forks:feat/mongoose-custom-id-type
Open

feat(db-mongodb): allow custom id field types#15522
MurzNN wants to merge 1 commit into
payloadcms:mainfrom
Murz-forks:feat/mongoose-custom-id-type

Conversation

@MurzNN

@MurzNN MurzNN commented Feb 5, 2026

Copy link
Copy Markdown

Summary

Allows setting the custom ID field type in the Mongoose adapter by adding a new argument idType: mongooseIDType and passing it to the function buildSchema().

No test coverage yet, cuz I'm pretty new with the Node.js tests and Payload contributions.

Why?

By default, Payload CMS creates docs using the MongoDB ObjectID as the ID value. But pretty often, the Payload's document IDs are reused in other database types, where the MongoDB's ObjectID value is not native and unclear.

The pretty popular ID value type in most modern databases is UUID, so for some projects, it would be much more convenient to use UUID in all Payload Collections by default.

Yes, we already can customize the ID field, according to the docs https://payloadcms.com/docs/fields/overview#custom-id-fields, but it should be done manually in each collection, so much better to allow choosing the default ID field type for the whole project.

And one more significant limitation of the current Payload Custom ID Field API is that even if we generate the UUID value in JS, it will be stored as a string, wasting 32-36 bytes per id and decreasing the database performance, instead of using the 16-byte binary storage.

This resolves the missing UUID type for MongoDB issue discussed in #13054

How?

  • Adds a new argument idType: mongooseIDType to the function mongooseAdapter().
  • Passes the value to the function buildSchema().
  • Uses the custom type for the _id field schema in the collections.

@MurzNN MurzNN force-pushed the feat/mongoose-custom-id-type branch from 6efd586 to da12084 Compare February 14, 2026 08:13
@MurzNN MurzNN marked this pull request as ready for review February 14, 2026 08:15
@MurzNN

MurzNN commented Feb 16, 2026

Copy link
Copy Markdown
Author

The UUID ID values work well with the provided changes, I see that in the Mongo database, they are stored as binary UUID values correctly, if I set the UUID type in the payload configuration like this:

{
    _id: UUID("e3145dea-e23a-4271-a1ac-3612cbee6802"),
    createdAt: ISODate('2026-02-14T08:12:09.840Z'),
    updatedAt: ISODate('2026-02-14T08:12:09.841Z'),
    email: 'dev@payloadcms.com',
    salt: 'e8f9[cut]',
    hash: '96de[cut]',
    loginAttempts: 0,
    __v: 0
}

But seems we have an issue with relationship fields, because they continue to expect the ObjectID there. So, I need some help from Payload developers to find the right places in the Payload core where to fix this.

@W1ckh3ad

Copy link
Copy Markdown
Contributor

Hey @MurzNN,

I saw your comment below my pr

Do you need help going forward?

How did implement the changes?
Did you use any AI Tools?

I let it plan by Claude Opus,
checked the changes and ran the integration tests locally
(you need docker for it)

I couldn't ran all e2e tests because if failed to close the running dev server, so it couldn't start the new one.

It was my first contribution to payload, if you need help you can ask me.
If you don't think you can implement it on your own, then I would need some time for this.

I would recommend you looking into my pr
watch for the files and texts changed
and try to get it planned by Claude and implement it with Cursor Editor

Fortunately it's very close to my changes.

Kind regards
Christopher :)

@MurzNN

MurzNN commented Apr 19, 2026

Copy link
Copy Markdown
Author

@W1ckh3ad, glad to hear that you're willing to help! Actually, I need a review of the overall approach and feedback about the implementation, and the next steps to move this forward to get merged into the Payload core.

The general functionality works (on my localhost 😆) - it creates ids using binary UUID instead of strings in MongoDB. But it seems not all Payload parts are covered, because on relationship fields it produces errors. But, I believe it should be an easy fix, just need to find the right place.

@github-actions github-actions Bot removed the stale label Apr 20, 2026
@denolfe denolfe added the v3 label Apr 23, 2026
@github-actions github-actions Bot added the stale label May 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants