How does a ULID differ from a UUID?
In the length of the written form and in the alphabet: a ULID takes 26 characters instead of 36 and needs no dashes, so it drops into a page address or a file name as it is. Both carry exactly 128 bits of data. By its layout a ULID is closest to a version 7 UUID: the first 48 bits are Unix time in milliseconds, the remaining 80 are random.
Why does a ULID sort by creation time?
Because the timestamp comes first and is written in an alphabet whose character order matches the order of their values. Because of that, identifiers sorted as plain strings also come out sorted by time. For a primary key this means new rows land at one edge of the index instead of scattering across it the way version 4 UUIDs do.
Is the order kept for identifiers from the same millisecond?
Yes, within a single run. Their timestamps match, so the random part is not drawn afresh but incremented from the previous value — the identifiers come out in ascending order. Across separate requests, and all the more across separate servers, that order is not guaranteed: there the values only differ by the timestamp.
Why are the letters I, L, O and U missing from a ULID?
Identifiers are written in the Crockford Base32 alphabet, which drops the characters that look like digits: I and L are confused with one, O with zero. The letter U is excluded separately so that no accidental profanity turns up inside an identifier. That leaves 10 digits and 22 letters — 5 bits per character, so 130 bits of written form cover 128 bits of data.