UUID Generator

A UUID is a 128-bit identifier designed to be generated independently by any number of separate systems, at any time, with no central coordinating authority handing out the next available number, while still having an overwhelming statistical guarantee that no two generated values will ever collide. This is fundamentally different from an auto-incrementing integer ID, which requires a single database to track and hand out the next number in sequence — a UUID can be generated on a phone with no network connection, in a serverless function, or across a thousand parallel microservice instances simultaneously, with no coordination between them required at all, because the sheer size of the number space makes an accidental collision astronomically unlikely regardless of how many are generated independently.

UUID version 4 fills essentially the entire 128 bits with cryptographically random data, which makes each generated value completely unpredictable and gives no clue whatsoever about when it was created or in what order relative to any other v4 UUID — exactly the property wanted for something like a security token, where predictability itself would be a vulnerability. UUID version 7, standardised far more recently in RFC 9562 (2024), deliberately sacrifices some of that opacity: it places a millisecond-precision timestamp in the leading bits, so a v7 UUID generated later always sorts after one generated earlier, while the remaining bits stay random and just as unguessable as v4's. The two are not competing designs where one is simply "better" — they trade the same underlying randomness for a different property depending on whether ordering or uniform unpredictability is what actually matters for a given use case.

A database index backing a primary key is typically stored as a B-tree, a structure that performs best when new values are inserted at or near the end of the existing sorted order — which is exactly how a traditional auto-incrementing integer key behaves. A UUID v4 primary key, being uniformly random, inserts at an effectively random position within that sorted structure every single time, which forces the database to repeatedly split and rebalance index pages scattered throughout the tree rather than simply appending to the end. At small scale this overhead is invisible; at scale, with millions of rows, it becomes a genuine and measurable source of index fragmentation and slower writes — the exact problem UUID v7's leading timestamp was standardised specifically to solve, since it lets a UUID keep unique, unguessable IDs while still inserting in roughly sequential order.