Short UUID Alternatives: ULID, NanoID, and More

Limitations of UUID

Although UUID is widely used, it has clear shortcomings in certain scenarios: length (36 characters or 32 without hyphens) is inelegant in URLs; UUID v4 has no temporal ordering, resulting in poor database index performance; not suitable as short IDs shown to users (like order numbers, invite codes); all-lowercase hexadecimal strings are not intuitive, with poor readability; in some scenarios sensitive to field length (SMS, QR code content), 36 characters is too long. The following alternatives are more suitable than UUID in specific scenarios.

ULID: Sortable UUID Alternative

ULID (Universally Unique Lexicographically Sortable Identifier) is an excellent solution to UUID's ordering problem: 26 characters (Crockford Base32 encoding), shorter than UUID's 36 characters; contains 48-bit millisecond timestamp + 80-bit random number, naturally sorted by generation time; alphabet uses only A-Z and 0-9 (excluding easily confused I, L, O, U), URL-safe; monotonic increment guarantee: multiple ULIDs generated within the same millisecond still maintain order; example: 01ARZ3NDEKTSV4RRFFQ69G5FAV. ULID is especially suitable as database primary keys while maintaining good readability.

NanoID: Shorter and Faster Random ID

NanoID is a lightweight random ID generation library that by default generates 21-character URL-safe IDs (using A-Za-z0-9_- alphabet). Compared to UUID v4: shorter (21 vs 36 characters), URL-safe (no hyphen issues), faster generation (approximately 2x), extremely small file size (JavaScript package only 108 bytes). NanoID supports custom length and alphabet, suitable for scenarios requiring flexible ID lengths. For example: generating 10-character IDs for short links, generating 6-digit numeric OTP codes. Note that NanoID has no temporal ordering, making it unsuitable as database primary keys (same as UUID v4).

Snowflake ID: Twitter's Distributed ID Scheme

Snowflake is Twitter's open-source distributed ID generation algorithm, generating 64-bit integer IDs: 1 sign bit (fixed at 0), 41-bit millisecond timestamp (approximately 69 years), 10-bit machine ID (up to 1024 machines), 12-bit sequence number (up to 4096 per millisecond). Snowflake ID advantages: integer type with highest storage and index efficiency; strictly ordered (4096 ordered IDs per node per millisecond); decodable — extract timestamp, machine ID, and sequence number from the ID; disadvantages: requires coordinated machine ID assignment (central coordination problem), clock rollback causes duplicate IDs (needs special handling), less universal than UUID. Snowflake is suitable for scenarios requiring extreme performance with central coordination capability.

Code Examples for Each Scheme

# ULID (Python)
# pip install python-ulid
from ulid import ULID
ulid = ULID()
print(str(ulid))  # 01ARZ3NDEKTSV4RRFFQ69G5FAV

# NanoID (Python)
# pip install nanoid
from nanoid import generate
id = generate()                   # 21 字符默认
short_id = generate(size=10)      # 10 字符
numeric_id = generate('0123456789', 6)  # 6 位数字

// NanoID (JavaScript)
// npm install nanoid
import { nanoid, customAlphabet } from 'nanoid';
console.log(nanoid());            // 21 字符
console.log(nanoid(10));          // 10 字符

const numeric = customAlphabet('0123456789', 6);
console.log(numeric());           // 6 位数字 OTP

// UUID v7 (最新标准，兼具时序性)
// npm install uuid
import { v7 as uuidv7 } from 'uuid';
console.log(uuidv7()); // 有时序的 UUID，格式同 UUID v4

Selection Guide: When to Use Which ID

• UUID v4: General purpose, no ordering requirements, with existing library support
• UUID v7: Database primary keys, temporal ordering needed, standard compatibility required
• ULID: Database primary keys, temporal ordering needed, prefer string format
• NanoID: URL slugs, short links, length-sensitive scenarios
• Snowflake: Ultra-high concurrency, with centralized coordination, requiring integer IDs
• Auto-increment integer: Small single-machine applications, scenarios where sequential IDs don't pose security issues