What This Video Covers
ID format comparison videos survey the landscape of distributed identifier formats — UUID, ULID, NanoID, Snowflake, KSUID — benchmarking them on length, sortability, randomness, ecosystem support, and database suitability.
Skill level: Intermediate Best for: Architects and developers deciding on an ID strategy for a new system
Key Concepts You Will Learn
1. The comparison matrix
| Format | Bits | Length | Sortable | RFC | DB native type |
|---|---|---|---|---|---|
| UUID v4 | 122 random | 36 chars | No | RFC 9562 | Yes (uuid) |
| UUID v7 | 74 rand + 48 ts | 36 chars | Yes | RFC 9562 | Yes (uuid) |
| ULID | 80 rand + 48 ts | 26 chars | Yes | No | No |
| NanoID | ~126 random | 21 chars | No | No | No |
| Snowflake | seq + node + ts | 18–20 chars | Yes | No | BIGINT |
| KSUID | 128 rand + 32 ts | 27 chars | Yes | No | No |
2. UUID v7 vs ULID
Both use the same 48-bit millisecond epoch. Key differences:
- Encoding: UUID uses lowercase hex (
xxxxxxxx-xxxx-7xxx-...); ULID uses Crockford Base32 (01ARYZ6S41TSSSTW9ZTS5KVSQQ) - Length: ULID is 26 characters vs UUID’s 36
- Random bits: ULID has 80 vs UUID v7’s 74
- Standard: UUID v7 is RFC 9562; ULID has no IETF standard
- Database: PostgreSQL
uuidtype accepts UUID v7 natively; ULID requirestextor a custom type
See UUID vs ULID — full comparison.
3. UUID v7 vs Snowflake IDs
Twitter’s Snowflake format: 41-bit timestamp (ms) + 10-bit machine ID + 12-bit sequence = 63 bits stored as BIGINT. UUID v7: 48-bit timestamp + 12-bit counter + 62-bit random = 122 bits stored as uuid.
Snowflake requires infrastructure: each generator node needs a unique 10-bit machine ID registered with a coordination service (Zookeeper, consul). UUID v7 requires nothing — any process generates without coordination. UUID v7 has more randomness (no machine ID fingerprinting) and a longer timestamp range. See UUID v7 in Distributed Systems.
4. NanoID — the short URL ID
import { nanoid } from 'nanoid';
const id = nanoid(); // "V1StGXR8_Z5jdHi6B-myT"
NanoID is ideal for short, human-friendly IDs in URLs. But it has no database native type, no timestamp, and no standard. Do not use it as a primary key in a relational database — use UUID v4 or v7 instead.
5. When each format wins
- UUID v7 — database primary keys, event IDs, anything stored long-term in a relational DB
- UUID v4 — tokens, share links, idempotency keys, externally visible IDs where creation time must not leak
- ULID — systems where the 10-char shorter string specifically matters (URLs, user-visible IDs)
- NanoID — client-side short IDs, URL slugs, where brevity is paramount and DB native type is not needed
- Snowflake — legacy systems already using BIGINT primary keys that need time-ordering
Related Reading
- UUID vs ULID — full comparison
- UUID v7 vs ULID — which to use in 2026
- UUID URL-Safe Encoding — Base64url and Base58
- UUID v7 in Distributed Systems
- UUID v4 vs v7 — full comparison
Watch on YouTube
Search for UUID vs other ID format comparison videos on YouTube ↗
Try the Tools
- Generate UUID v7 or v4
- UUID Converter — see UUID in all encoding formats
- UUID Decoder — inspect version, variant, timestamp
Frequently asked questions
Should I use UUID v7 or ULID for sortable IDs?
In 2026, UUID v7 is the better default. It has RFC standardisation (RFC 9562), native PostgreSQL 18 support, and stores in the existing uuid column type. ULID has no RFC standard and requires custom storage. Choose ULID only if shorter 26-char strings are important for your use case.
What is the shortest way to encode a UUID in a URL?
Base64url encoding reduces a UUID from 36 characters (hyphenated string) to 22 characters with no padding. Strip the trailing == padding — the length is always 22. Alternatively, Base58 also produces 22 characters with no padding and no special URL characters. Both are fully reversible to the original 16-byte UUID. The uuid npm package includes uuidStringify and uuidParse for byte-level access.
Should I use v4 or v7?
Use v7 for database primary keys (time-sortable, index-friendly) and v4 for anything where creation order could leak information, like tokens or share links.
Should I use UUID v7 or ULID in 2026?
UUID v7 is the better default in 2026. It has RFC standardisation (RFC 9562), native PostgreSQL 18 support, and stores in the existing uuid column type without schema changes. ULID uses the same 48-bit millisecond timestamp + 80 random bits (vs UUID v7's 74) and a Crockford Base32 string (26 chars vs 36). Choose ULID only if the shorter string is specifically important. See UUID v7 vs ULID — full comparison.
What is NanoID and how does it compare to UUID?
NanoID is a URL-safe random ID library (not a standard) that generates compact strings using a customisable alphabet and length. A default NanoID (21 characters) has ~126 bits of randomness — similar to UUID v4's 122 bits. Unlike UUID, NanoID has no timestamp, no standard format, and no native database type support. It is best for short client-side IDs where human readability matters. For database primary keys, use UUID v4 or v7. See UUID URL-Safe Encoding for compact UUID alternatives.