Ask HN: We just had an actual UUID v4 collision...

Re:Ask HN: We just had an actual UUID v4 collision... by dgellow on Friday May 08, 2026 @06:37AM (#48061226)

How confident are you that your machines clocks are in perfect sync? What about the risk of clock drift + correction, or hardware issues?

[ Parent | on HN ]

Re:Ask HN: We just had an actual UUID v4 collision... by croon on Friday May 08, 2026 @08:04AM (#48061893)

Not GP, but: not confident. How confident would I be to avoid a (slightly lower entropy) UUID collision while also avoiding a clock desync landing on the exact same logged millisecond? Very, which is how confident I was about not encountering an UUID collision before this thread, so very++ I guess.

[ Parent | on HN ]

Re:Ask HN: We just had an actual UUID v4 collision... by kdps on Friday May 08, 2026 @04:23PM (#48068310)

I get why sync of mutiple machines matters for ordering and causality, but why is it a problem for uniqueness?

[ Parent | on HN ]

Re:Ask HN: We just had an actual UUID v4 collision... by dgellow on Saturday May 09, 2026 @07:28AM (#48074060)

I just read UUIDv7, something I wasn't familiar with until now. That does address everything I had in mind yes. I assumed timestamp-uuid meant purely based on the timestamp precision, in which case you can get conflicts if you don't have a reliable clock across your system.

But UUIDv7 looks pretty awesome:

> What is a Version 7 UUID made from?

> unix_ts_ms: 019e0c7bfe93

> ver: 7

> rand_a: 0b6

> var: b

> rand_b: 55a99e023294673

So please ignore my previous comment :)

[ Parent | on HN ]