MongoDB-style ObjectIDs

MongoDB began as a by-product. 10gen, founded in New York in 2007 by Dwight Merriman, Eliot Horowitz and Kevin Ryan — Merriman and Ryan both out of DoubleClick — was building a hosted application platform called Babble. The datastore underneath it turned out to be the interesting part, and in 2009 the company released that on its own as MongoDB; it renamed itself MongoDB, Inc. in 2013.

The ObjectID follows from one design decision in that database: a document's _id is filled in by the driver, on the client, before the server ever sees the insert. That rules out a server-side sequence, so the identifier has to be unique without any coordination at all. The twelve-byte answer put the creation time first — four bytes of Unix seconds, big-endian — which buys two things at once. Sorting on _id approximates sorting by insertion time, and the time can be read back out of the identifier, which is why the shell offers ObjectId.getTimestamp(). Twelve bytes rather than a UUID's sixteen also keeps the index a little smaller.

The original remaining eight bytes were a three-byte machine identifier, commonly derived from the hostname, two bytes of process id, and a three-byte counter starting from a random value. Containers broke that reasoning: replicas of one image can share a hostname and see the same process ids, so the two fields that were supposed to separate generators stopped doing so. MongoDB 3.4, released in 2016, replaced both with five bytes picked once per process, which is the layout the driver specification still describes.

ObjectID has aged into prior art. It is cited alongside Twitter's Snowflake from 2010 and Alizain Feerasta's ULID from 2016 as one of the time-ordered identifiers that persuaded the IETF to add a time-ordered UUID, which arrived as version 7 in RFC 9562 in May 2024.

Key properties

• An ObjectID is 12 bytes, written as 24 hexadecimal characters.
• The current layout is a 4-byte big-endian Unix timestamp in seconds, a 5-byte value generated once per process, and a 3-byte counter that starts from a random value.
• Before MongoDB 3.4 the middle five bytes were a 3-byte machine identifier followed by a 2-byte process id instead.
• The timestamp counts whole seconds, not milliseconds, so two ObjectIDs made in the same second are ordered only by the trailing counter — which orders IDs from one process and says nothing about IDs from another.
• Four bytes of seconds covers about 136 years from 1970, so the field as specified runs out on 7 February 2106.
• ObjectID is BSON type 0x07 and is the default value MongoDB supplies for the _id field, which is uniquely indexed and cannot be changed after insert.
• Twelve bytes against a UUID’s sixteen makes every index entry and every reference four bytes smaller.
• The IDs on this page are generated from a seeded, non-cryptographic PRNG and are reproducible from the URL, so they are fixture data rather than real identifiers.

Where they turn up

• Every MongoDB collection uses one as the default _id unless the application supplies its own, which makes the 24-character hex string a familiar sight in URLs of applications built on the database.
• MongoDB Extended JSON wraps them as {"$oid": "…"} so that mongoexport dumps and test fixtures can round-trip the type through plain JSON.
• Because the creation time is embedded, a range query on _id works as a crude date filter and is sometimes used to page through a collection in insertion order without a separate timestamp index.
• That same embedded time is an information leak when ObjectIDs are exposed publicly: anyone holding one learns, to the second, when the record was created.
• The format is regularly reimplemented outside MongoDB — in logging and queueing systems that want a short, sortable, coordination-free identifier — which is why plenty of 24-hex-digit IDs in the wild never touched the database.