UUID and KSUID in comparison

KSUID, UUIDv4, and UUIDv7 all provide decentralized unique identifiers, but they optimize for different properties: entropy source, sortability, privacy, and ecosystem support.

Structure and entropy

• KSUID: 160 bits total; 32‑bit timestamp (custom epoch, 1‑second resolution) + 128‑bit cryptographic‑random payload. Lexicographically sortable via big‑endian timestamp and base62 text encoding. GitHub reference ↗.
• UUIDv4: 128 bits; ~122 random bits plus version/variant. No embedded time component; purely random per RFC. Strong ecosystem and native DB types. Wikipedia ↗.
• UUIDv7: 128 bits; leading 48‑bit big‑endian Unix‑epoch timestamp (~1 ms), remaining bits random and optionally a counter to improve monotonicity. Lexicographically sortable and standardized in RFC 9562. Wikipedia ↗, UUIDv7 overview ↗.

Ordering and index locality

• KSUID: Naturally time‑sortable in both binary (20 bytes) and base62 text (27 chars). Improves insert locality for append‑heavy tables and S3/object-key grouping. GitHub ↗.
• UUIDv4: Not sortable by creation time; random distribution harms clustered index locality and can fragment B‑trees.
• UUIDv7: Time‑sortable by design; improves clustered index locality, partitioning by time, and write amplification versus v4. Widely discussed for database performance benefits. UUIDv7 Benefits ↗.

Collision resistance and coordination

• KSUID: 128 random bits yields extremely low collision probability; no coordination required. Timestamp does not reduce entropy; fixed-length formats help safe parsing. GitHub ↗.
• UUIDv4: Similar collision profile with 122 random bits; coordination-free and ubiquitous. Wikipedia ↗.
• UUIDv7: Entropy comparable to v4; optional counters enhance monotonicity under high concurrency; still coordination-free. Wikipedia ↗.

Privacy and metadata exposure

• KSUID: Leaks coarse creation time (seconds) but no host identifiers; safer than v1/Flake. ksuid.net ↗.
• UUIDv4: No time leakage; privacy-friendly.
• UUIDv7: Leaks millisecond‑precision creation time; assess business/privacy implications for public IDs. Reddit discussion ↗.

Text and binary representation

• KSUID: 20‑byte binary; 27‑char base62 text, delimiter‑free, lexicographically sortable, copy‑paste friendly. GitHub ↗.
• UUIDv4/v7: Canonical 36‑char hex with dashes (8-4-4-4-12); most DBs support native UUID types and binary storage. Storing as CHAR(36) is common; BINARY(16) preferred for efficiency. Stack Overflow ↗, Wikipedia ↗.

Ecosystem and standards

• KSUID: Reference Go library, multi-language ports; not an IETF/ISO standard but widely used. GitHub ↗.
• UUIDv4: Longstanding standard with broad tooling and DB-native support. Wikipedia ↗.
• UUIDv7: Newly standardized in RFC 9562; growing library and DB support; intended for modern database keys. Wikipedia ↗, UUIDv7 Benefits ↗.

Practical guidance

• Prefer KSUID when you need lexicographic time ordering plus strong randomness, friendly delimiter‑free text IDs, and no host metadata. GitHub ↗.
• Prefer UUIDv4 when you need simple, privacy‑preserving random IDs with maximal ecosystem support and do not require time ordering.
• Prefer UUIDv7 when database write locality, time‑based partitioning, and natural ordering are important, and timestamp leakage is acceptable. It aligns cleanly with clustered indexes and time-range queries. UUIDv7 Benefits ↗.

In short: KSUID and UUIDv7 both add time-sortability; KSUID uses base62 and second-level timestamps, UUIDv7 follows the RFC with millisecond timestamps and native UUID tooling; UUIDv4 remains the simplest and most privacy-preserving but hurts index locality.