UUID can be suboptimal for many uses-cases because:
Instead, herein is proposed ULID:
From the community!
| Language | Author | | -------- | ------ | | Javascript | alizain | | Erlang | savonarola | | Elixir | merongivian | | Go | imdario | | Java | Lewiscowles1986 | | Julia | ararslan | | .NET | RobThree | .NET | fvilers | PHP | Lewiscowles1986 | | Python | mdipierro | | Ruby | rafaelsales |
Below is the current specification of ULID as implemented in this repository.
``` 01AN4Z07BY 79KA1307SR9X4MV3
|----------| |----------------| Timestamp Randomness 10 chars 16 chars 50bits 80bits base32 base32 ```
Timestamp - 48 bit integer - UNIX-time in milliseconds - Won't run out of space till the year 10895 AD.
Randomness - 80 bits - Cryptographically secure source of randomness, if possible
The left-most character must be sorted first, and the right-most character sorted last (lexical order). The default ASCII character set must be used. Within the same millisecond, sort order is not guaranteed
Crockford's Base32 is used as shown. This alphabet excludes the letters I, L, O, and U to avoid confusion and abuse.
0123456789ABCDEFGHJKMNPQRSTVWXYZ
The components are encoded as 16 octets. Each component is encoded with the Most Significant Byte first (network byte order).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32_bit_uint_time_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16_bit_uint_time_high | 16_bit_uint_random |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32_bit_uint_random |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32_bit_uint_random |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
``` ttttttttttrrrrrrrrrrrrrrrr
where t is Timestamp r is Randomness ```
Partly inspired by: - instagram-engineering - firebase