UUID v4 vs timestamp-based IDs: a requirement checklist

Decision reference

List the properties before the format

Record whether writers are independent, whether IDs must sort by time and whether a legacy field limits length. Include indexing behavior, external references and public URL requirements. A convenient fixture format may not fit production storage. Keeping a requirement list makes later changes easier to evaluate and prevents visual preferences from deciding an architectural property accidentally.

Evaluate v4 against actual storage

Random UUIDs can be created offline with secure randomness and carry no timestamp. Their random ordering may affect index locality in some workloads. Benchmark the real database and write pattern rather than assuming every engine behaves alike. Random IDs avoid an obvious sequential count, but access control remains necessary. The tool generates v4 only and makes no claim to implement other UUID versions.

Understand timestamp duplication

Two events can occur in the same clock tick, especially across writers. Clocks can differ or move backward. Adding a sequence, worker ID or random suffix changes the design and creates additional rules. Date.now alone is not a general uniqueness guarantee. Standardized time-oriented schemes have their own requirements; verify their specification and supported implementation before adopting one.

Plan migration and conflict behavior

Test duplicate inserts, parsing, database mappings and full-length UI copying. If replacing a scheme, preserve old references and assess external integrations. Compatibility can matter more than the aesthetic benefit of a new identifier. Keep uniqueness enforced by storage and define retries or failures. A small synthetic batch is useful for interface tests, but cannot prove uniqueness at every future scale.

Worked example: why time alone repeats

Use this exact sample to isolate the behavior discussed above. Keep the operation and options with the sample when reporting a result; changing the input representation can change what the test demonstrates.

Input or question

Writer A: 1728000000000
Writer B: 1728000000000

Expected result or interpretation

Both raw millisecond IDs are equal. A separate uniqueness strategy is needed.

Ordering and uniqueness can conflict with an easy fixture

Two synthetic events created in the same millisecond are enough to disprove uniqueness for a raw Date.now ID strategy. Sorting the shared value also cannot determine their relative order. Adding a counter requires deciding where that counter lives and how multiple writers coordinate; adding randomness requires its own size and collision policy. This is a design change, not a formatting trick. Keep the simultaneous-event fixture in the selection process alongside an offline-writer case. If your requirement is simply a small independent record identifier, random v4 may fit. If it includes chronological ordering, choose a documented scheme that actually carries and defines that property.

Turn format selection into a small design record

Create a comparison table for the actual application rather than a general ranking of identifier names. Include writer coordination, required ordering, public exposure, database representation and legacy integrations. Mark which requirements are mandatory and which are preferences. A format that fails a mandatory condition should not win because its text is shorter or looks more familiar.

Use workload tests for storage questions. Random keys can interact with index locality, while time-oriented keys can expose ordering information and depend on their scheme’s generation rules. Test the selected implementation under concurrent writers and define conflict handling. For any timestamp-derived approach, include a simulated repeated clock tick and backward clock movement if the design depends on wall time. Do not reinvent a standard format by concatenating fields without specifying ranges, collision behavior and serialization. If migrating an existing system, include old ID parsing, foreign references, backups and external links in the record. A new generator is only one part of the change. The browser tools support practical examples of v4 generation and time conversion, but they do not choose your database architecture or implement every identifier standard. Keep their role as inspection aids clearly stated in the decision.

Verification cases

• Two writers in the same millisecond: Raw time values can collide.
• Need chronological sort: Random v4 does not meet that requirement.
• Existing external references: Plan compatibility before migration.

Before you use the result

1. List coordination and ordering requirements.
2. Benchmark the real database workload.
3. Do not use time alone as a uniqueness proof.
4. Plan old-reference compatibility.

Continue the workflow

UUID v4 in practice: randomness, collisions and database checks addresses generate and use random uuid identifiers. Unix seconds vs milliseconds: diagnose a timestamp unit mismatch addresses convert epoch timestamps with explicit units.