Hashes, IDs, and randomness
Does a UUID contain a timestamp? Compare v4 and v7
Tools to use
Choosing UUID v4 or v7 starts with what you expect from an ID. Both have the same textual length, but random-centred v4 and timestamp-prefixed v7 reveal different information when ordered. Generate a few and inspect a known example. This experiment does not decide database performance or authentication security.
Look at the version field, not just the hyphens
xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx (v4)
xxxxxxxx-xxxx-7xxx-yxxx-xxxxxxxxxxxx (v7)A UUID is 128 bits, conventionally written as 32 hexadecimal digits separated by hyphens. The first digit of the third group locates the version. The diagram uses placeholders, not valid UUID input. Matching length and punctuation alone is not complete format validation.
Paste one generated UUID back into the input to inspect it rather than generate a count. Check version and variant. This is single-value inspection, not bulk validation of multiple lines. First confirm that the inspected version matches your generation choice.
Sorting v4 does not recover creation order
Generate five v4 values, then sort them in Line Tools. v4 has no creation-time field for this purpose, so lexical order does not recover generation order. An accidental match is not timestamp extraction. Consider a separate creation time or ordering field when chronology matters.
Random IDs differ from obvious counters, but they do not make an endpoint safe if knowing an ID bypasses authorization. Separate public identity from access checks. A handful of nonduplicate samples also does not prove absolute uniqueness.
v7 includes a millisecond timestamp
017f22e2-79b0-7cc3-98c4-dc0c0c07398f
1645557742000 ms
2022-02-22T19:22:22.000ZInspect this UUID to see version 7, Unix milliseconds 1645557742000 and its UTC representation. v7 places Unix milliseconds in its first 48 bits, so ordered canonical values with different timestamps reflect that time component. This differs from v4's lack of a creation-time ordering field.
Readable time does not prove who generated it or that their clock was correct. This is a published fixed example, and values can be copied or constructed. Treat the decoded timestamp as reference information; consider whether exposing time in a public ID fits your requirements.
Be careful with one millisecond and multiple generators
Ordering within one millisecond depends on the remaining bits and generator state. SheepDev uses its installed uuid library, but does not guarantee one global order across devices, processes or restarts. Clock differences also mean critical event ordering should not be inferred from IDs alone.
Check how a database UUID type or custom binary layout compares values. Successful line sorting does not establish index order or query behaviour. Verify the storage format, comparator and real query with a small controlled dataset.
v7 is not an automatic database speedup
Time ordering can be useful in storage design, but performance depends on indexes, data volume, write patterns and queries. This tool neither connects to a database nor benchmarks it. State the requirement first—timestamp-bearing or random identity—and measure actual workloads if performance is the reason.
Record version, format result, any v7 reference time, and whether you generated or inspected the value. Valid format is not trust. Keep application uniqueness and authorization checks separate, and distinguish a small experiment from operational guarantees.