MongoDB :: using String instead of default ObjectId type for _id?

Question

There is this question which asks essentially the same question but is three questions in one and the 1/3 I'm after isn't really answered very well so I'm asking it again:

I'm starting an new MongoDB project (in NodeJS). For the required document _id field I'm considering using the string serialization of an ObjectId instead of MongoDB's default ObjectId (i.e. setting { _id: String(mongodb.ObjectId()), ...} instead of inbuilt default). Tell me why shouldn't I do this?

In general the argument for, is it makes comparisons easier:

• If I grab an object identifier off the wire or out of some JSON document, I don't need to hydrate it into an ObjectId before doing comparison queries in a find or aggregation pipeline. And I don't need to know a priori a given field is an ObjectId and special case it.
• It saves confusing about comparison in code if object identifiers are just always a strings. For example in NodeJS <ObjectId> === <String> is always false you have to use ObjectId.equals or ==.

I gather there was a very good reason MongoDB decided to use ObjectId over just strings. I mean sure, I can see some potential advantages but I never understood or found any clear documentation outlining why they did this.

Answer 1

Why shouldn't I do this? Having reflected on this I decided to not use a stringification of ObjectId over ObjectId. Reasons:

First, ObjectId is 12 bytes, not 24 bytes as @Wernfried pointed out.

Second, I'm using Typescript. Using Typescript and typing DB schema can remove much of the ambiguity around what your comparing. Yes _id as raw string is convenient sometimes, but convenient in the similar way scripting language is convenient over typed one - you'll pay for it when project becomes large.

Third, the mongodb docs state there is two benefits to using ObjectId:

1. In mongosh, you can access the creation time of the ObjectId, using the ObjectId.getTimestamp() method.
2. sorting on an _id field that stores ObjectId values is roughly equivalent to sorting by creation time

Point 1 isn't very useful and you can create an ObjectId from a string value trivially anyway. However, the aggregation date expression operators actually work with ObjectIds too.

Fourth, _id field is immutable so if you ever want to change it back you'll have to recreate each document with new _id value.

Fifth, a vague reason is along the lines of forward compatibility. Like for example, you can't currently use _id as a TTL index even though it contains a timestamp and work with other date operators. Maybe MongoDB will release that in future.

Finally, I've heard it can be indexed better but I'm not sure that's actually true (maybe in the Enterprise version or something ..) and haven't found any doc on it. A quick very basic test of random lookup in v5.0.9 show identical performance - for lookup.

Probably there are other arguments against I've missed. But in summary, although there may be legit use cases for using a unique strings for _id, if your just going to set it to the string value of an ObjectId it's probably not worth it on balance.