| Wow, thanks this was more than I expected. Here's my considerations on your reply, though it's likely not useful for you, but it is good for me to write this out. 1) DB performance has as much (or more) todo with time sorting as anything. But I am not an expert, I just rely on what I read from others. (hence, my questions to you, and I appreciate your time/effort on your responses here) But, I do appreciate the inherit use of a time part, just makes me feel better about having a "randomish" id, but not loosing what I felt I had previously with incremented integers. 2) This is one reason I _prefer_ ULID to other options. I am using ULIDs in low count generated IDs per second, and I want to use in them in URLs. All lowercase is a trivial thing to implement. And I remove ambiguity about content (ie, 1,i,I,L, etc...) So for human readable ULID is almost unparalleled from what I have found. Is there another UID system that is just as human readable? I'd love to find something else to compare it to. (that I haven't already) 3) #2 dove-tails into #3 I guess, but yes, I look at data all day long, and the shorter the better. The fewer conflicts, misunderstandings, etc... the more human readable it is. Is there another UID that is _more_ human readable? 4) I don't need my UIDs to be special, I just need them to be useful. Why is something "odd" to you because of an arbitrary number like "80 bits"? Am I missing something about unique ids that require a specific hex/octet/base-10 value or they don't work properly? As far as I know _all_ unique ids have the potential for conflicts, there is no getting around this. A) I don't have any issues with making more than one ULID per millisecond, I spend way more CPU time on other things, I have no issue holding back ULID generation to avoid the "countable" error of multiple ULIDs that can be guessed. Thank you for pointing out this flaw, it would be nice if it didn't exist, and maybe the libraries should have some kind of flag/option to enable guaranteed random values at the cost of speed. (which considering how long it takes to download very large background video on a splash/hero banner on a site, I think solves what seems to be 100% of the criticisms you have against ULIDs. B) Here's a discussion about ULID vs KSUID, which includes replies from the author you linked to from Segment, Rick Branson. https://github.com/segmentio/ksuid/issues/8 Rick says this about ULID vs KSUID: "If one is concerned about the extra 4 bytes of data or if millisecond precision is needed, then ULID is probably a better choice." It seems that ULID has some advantages over KSUID, and it's not so cut and dry that KSUID is superior in all ways. |