v4 or v7?
UUID v4 is 122 random bits. It reveals nothing about when or where it was made, which is why it is the default almost everywhere.
UUID v7 (RFC 9562, 2024) starts with a 48-bit millisecond timestamp, followed by random bits. New IDs sort after old ones, so database indexes stay compact. Random v4 keys scatter inserts across a B-tree, while v7 keys append to the end, the way an auto-increment ID does. Use v7 for primary keys. Use v4 when the creation time shouldn’t be visible, for example in a public URL.
Reading a UUID
In 0190c2a4-8f2b-7c3e-9a41-5f0d2e6b7c18, the first digit of the third group is the version (7). The first digit of the fourth group is the variant: 8, 9, a or b means a standard RFC UUID. Paste any UUID into the inspector to see its version and variant, and the time it was created if it’s a v1 or v7.
Are collisions possible?
In theory, yes. In practice, no: you would need to generate about 2.7 quintillion v4 UUIDs to reach a 50% chance of a single collision. The real risk is a weak random number generator. This page uses crypto.getRandomValues, the browser’s cryptographic generator.
In code
// JavaScript (browsers and Node 19+)
crypto.randomUUID(); // v4
// Java
UUID.randomUUID(); // v4
// Python
import uuid
uuid.uuid4()
uuid.uuid7() # Python 3.14+
// PostgreSQL
SELECT gen_random_uuid(); -- v4
SELECT uuidv7(); -- PostgreSQL 18+ Store UUIDs in a native uuid column (PostgreSQL) or BINARY(16) (MySQL), not as 36-character strings. That cuts index size by more than half.