Top Related Projects
K-Sortable Globally Unique IDs
Quick Overview
ULID (Universally Unique Lexicographically Sortable Identifier) is a specification for creating unique, time-ordered identifiers. It combines the benefits of UUIDs and timestamps, providing a 128-bit identifier that is both unique and sortable.
Pros
- Lexicographically sortable, allowing for efficient database indexing and sorting
- Time-based, making it possible to extract creation time from the identifier
- Shorter than UUID when encoded in Base32 (26 characters)
- Monotonicity within the same millisecond, ensuring proper ordering
Cons
- Less widely adopted compared to UUID
- Potential for timestamp collisions in high-volume systems
- Requires careful implementation to ensure proper monotonicity
- May expose creation time, which could be a privacy concern in some cases
Code Examples
Since ULID is a specification rather than a specific code library, implementations exist in various programming languages. Here are a few examples using different language implementations:
JavaScript (using the ulid package):
import { ulid } from 'ulid'
const id = ulid()
console.log(id) // 01ARZ3NDEKTSV4RRFFQ69G5FAV
Python (using the ulid-py package):
from ulid import ULID
id = ULID()
print(str(id)) # 01ARZ3NDEKTSV4RRFFQ69G5FAV
Go (using the oklog/ulid package):
package main
import (
"fmt"
"github.com/oklog/ulid/v2"
)
func main() {
id := ulid.Make()
fmt.Println(id.String()) // 01ARZ3NDEKTSV4RRFFQ69G5FAV
}
Getting Started
To use ULID in your project, you'll need to choose an implementation for your programming language. Here's a general approach:
- Install the ULID library for your language (e.g.,
npm install ulidfor JavaScript) - Import the library in your code
- Generate a ULID using the library's provided function
- Use the generated ULID as needed in your application
For specific implementation details, refer to the documentation of the ULID library for your chosen programming language.
Competitor Comparisons
K-Sortable Globally Unique IDs
Pros of KSUID
- Lexicographically sortable without any special encoding
- Includes a timestamp with 1-second resolution
- Slightly more compact than ULID (20 bytes vs 26 bytes)
Cons of KSUID
- Less widely adopted compared to ULID
- Does not support custom entropy sources
- Lacks millisecond precision in timestamp
Code Comparison
KSUID:
id := ksuid.New()
fmt.Printf("%s", id)
ULID:
t := time.Now()
entropy := ulid.Monotonic(rand.New(rand.NewSource(t.UnixNano())), 0)
id := ulid.MustNew(ulid.Timestamp(t), entropy)
fmt.Printf("%s", id)
Both KSUID and ULID are unique identifier systems designed to address limitations of UUID. KSUID, developed by Segment, offers a more compact representation and natural lexicographic sorting. ULID, on the other hand, provides millisecond precision and supports custom entropy sources, making it more flexible for various use cases. While KSUID is simpler to implement, ULID has gained wider adoption in the developer community. The choice between the two depends on specific project requirements, such as sorting needs, timestamp precision, and compatibility with existing systems.
Convert 
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
Universally Unique Lexicographically Sortable Identifier
UUID can be suboptimal for many use-cases because:
- It isn't the most character efficient way of encoding 128 bits of randomness
- UUID v1/v2 is impractical in many environments, as it requires access to a unique, stable MAC address
- UUID v3/v5 requires a unique seed and produces randomly distributed IDs, which can cause fragmentation in many data structures
- UUID v4 provides no other information than randomness which can cause fragmentation in many data structures
Instead, herein is proposed ULID:
ulid() // 01ARZ3NDEKTSV4RRFFQ69G5FAV
- 128-bit compatibility with UUID
- 1.21e+24 unique ULIDs per millisecond
- Lexicographically sortable!
- Canonically encoded as a 26 character string, as opposed to the 36 character UUID
- Uses Crockford's base32 for better efficiency and readability (5 bits per character)
- Case insensitive
- No special characters (URL safe)
- Monotonic sort order (correctly detects and handles the same millisecond)
Implementations in other languages
From ourselves and the community!
Specification
Below is the current specification of ULID as implemented in ulid/javascript.
Note: the binary format has not been implemented in JavaScript as of yet.
01AN4Z07BY 79KA1307SR9X4MV3
|----------| |----------------|
Timestamp Randomness
48bits 80bits
Components
Timestamp
- 48 bit integer
- UNIX-time in milliseconds
- Won't run out of space 'til the year 10889 AD.
Randomness
- 80 bits
- Cryptographically secure source of randomness, if possible
Sorting
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
Canonical String Representation
ttttttttttrrrrrrrrrrrrrrrr
where
t is Timestamp (10 characters)
r is Randomness (16 characters)
Encoding
Crockford's Base32 is used as shown. This alphabet excludes the letters I, L, O, and U to avoid confusion and abuse.
0123456789ABCDEFGHJKMNPQRSTVWXYZ
Monotonicity
When generating a ULID within the same millisecond, we can provide some
guarantees regarding sort order. Namely, if the same millisecond is detected, the random component is incremented by 1 bit in the least significant bit position (with carrying). For example:
import { monotonicFactory } from 'ulid'
const ulid = monotonicFactory()
// Assume that these calls occur within the same millisecond
ulid() // 01BX5ZZKBKACTAV9WEVGEMMVRZ
ulid() // 01BX5ZZKBKACTAV9WEVGEMMVS0
If, in the extremely unlikely event that, you manage to generate more than 280 ULIDs within the same millisecond, or cause the random component to overflow with less, the generation will fail.
import { monotonicFactory } from 'ulid'
const ulid = monotonicFactory()
// Assume that these calls occur within the same millisecond
ulid() // 01BX5ZZKBKACTAV9WEVGEMMVRY
ulid() // 01BX5ZZKBKACTAV9WEVGEMMVRZ
ulid() // 01BX5ZZKBKACTAV9WEVGEMMVS0
ulid() // 01BX5ZZKBKACTAV9WEVGEMMVS1
...
ulid() // 01BX5ZZKBKZZZZZZZZZZZZZZZX
ulid() // 01BX5ZZKBKZZZZZZZZZZZZZZZY
ulid() // 01BX5ZZKBKZZZZZZZZZZZZZZZZ
ulid() // throw new Error()!
Overflow Errors when Parsing Base32 Strings
Technically, a 26-character Base32 encoded string can contain 130 bits of information, whereas a ULID must only contain 128 bits. Therefore, the largest valid ULID encoded in Base32 is 7ZZZZZZZZZZZZZZZZZZZZZZZZZ, which corresponds to an epoch time of 281474976710655 or 2 ^ 48 - 1.
Any attempt to decode or encode a ULID larger than this should be rejected by all implementations, to prevent overflow bugs.
Binary Layout and Byte Order
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_high |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16_bit_uint_time_low | 16_bit_uint_random |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32_bit_uint_random |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32_bit_uint_random |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prior Art
Partly inspired by:
Top Related Projects
K-Sortable Globally Unique IDs
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot