Comments by "Mikko Rantalainen" (@MikkoRantalainen) on "The Problem With UUIDs" video.

  1. 15:20 I don't understand this argument. If you're happy to store 32 bit integer in binary form, you should be happy to store the 128 bit UUID in binary form, too. The database can convert from binary value to human readable value on the fly, just the way it happens for binary 32 bit integers, too! With the same logic you could argue that 128 bit binary UUID is actually better format than 32 bit integer stored as base-10 number as a string. That said, if your database doesn't support UUID column type, maybe you should switch database.
    3
  2. I think V8 would be more accurate to explain as V4 + 2 extra random bits. V4 has 122 random bits and V8 has logically 124 random bits. V7 is V1 with opaque/random node identifier + no offset to UNIX epoch.
    2
  3. A correctly implemented UUID v1 will definitely be unique for all machines correctly following the spec. However, correctly implementing UUID v1 requires real synchronization within one system and many programs that want to create UUID v1 identifiers are not synchronized to each other. In addition, it requires using real non-duplicated MAC address. In fact, in many implementations v1 identifiers are not synchronized even between threads in a single process because actually correctly implementing the full UUID v1 spec is hard.
    1
  4. For a big systems, the rationale for keeping closely generated ids close to each other in the index. In reality, the generated ids are used in context with the surrounding content or data. The ids generated nearly the same time in a big system are only rarely related to each other so it makes zero sense to keep those close to each other in the index. (Imagine something like Gmail. Do you think it makes any sense to keep all the mail received near 2024-05-01 13:00:00? How often do you need to go through all the mail received near that time in the future?)
    1