Byte-Level Anatomical Breakdown of Distributed IDs
Comparing distributed identifier standards requires examining their exact binary memory footprints and bitwise layout:
1. UUID Family (RFC 9562, which obsoletes RFC 4122) — 128 Bits (16 Bytes)
- UUIDv4: 122 random bits (RFC 9562 recommends a CSPRNG, but actual quality depends on the implementation), 4 bits of version (
0100), and 2 bits of variant (10). Total combinations: 2122 ≈ 5.3 × 1036. Collision probability is negligible, but randomness creates chaotic memory layouts. - UUIDv7 (Modern Standard): Solves UUIDv4's B-Tree problem by encoding a 48-bit Unix millisecond timestamp at the highest-order bits, followed by version and 74 random bits. Highly index-friendly while maintaining 128-bit global uniqueness.
2. MongoDB ObjectId — 96 Bits (12 Bytes)
Consists of 12 bytes formatted as 24 hexadecimal characters:
- 4 Bytes: Unix timestamp in seconds.
- 5 Bytes: Process unique value (generated once per machine/process).
- 3 Bytes: Monotonically incrementing counter initialized to a random value.
3. Twitter Snowflake — 64 Bits (8 Bytes)
flowchart LR
S1["1 Bit: Sign (Always 0)"] --- S2["41 Bits: Millisecond Timestamp (69 Years)"]
S2 --- S3["10 Bits: Machine / Datacenter ID (1,024 Nodes)"]
S3 --- S4["12 Bits: Sequence Counter (4,096 IDs/ms)"]
Bitwise Memory & Index Performance Comparison
| Identifier | Size (Bytes) | B-Tree Locality | Time Sortable? | Throughput per Node |
|---|---|---|---|---|
| UUIDv4 | 16 bytes (128 bits) | Poor (random inserts; worst for clustered indexes such as InnoDB and SQL Server, milder for PostgreSQL heap tables where only the index suffers) | No | Practically unlimited (local PRNG) |
| UUIDv7 | 16 bytes (128 bits) | Excellent (append-only) | Yes (millisecond) | Practically unlimited |
| ObjectId | 12 bytes (96 bits) | Good | Yes (second) | 16.7M IDs / sec per process (224 counter) |
| Snowflake | 8 bytes (64 bits) | Optimal (fits in BIGINT) | Yes (millisecond) | 4,096,000 IDs / sec |