Generate UUID v4 instantly — bulk, formatted, cryptographically random
Uses timestamp + MAC address. Sortable chronologically but leaks machine info. Used in Cassandra, Snowflake-style IDs.
122 bits of random data. Most common for general-purpose IDs in databases, APIs, and distributed systems.
SHA-1 hash of a namespace + name. Same input always produces same UUID. Useful for deterministic IDs.
Time-ordered random UUID (RFC 9562). Sortable like v1 but random like v4. Growing adoption in modern databases.
A UUID (Universally Unique Identifier) is a 128-bit label in the format 8-4-4-4-12 hex digits. Example: 550e8400-e29b-41d4-a716-446655440000. Used to uniquely identify records in databases, APIs, and distributed systems.
Practically yes. UUID v4 has 2^122 ≈ 5.3 × 10^36 possible values. Generating 1 billion UUIDs/second for 85 years gives only a 50% chance of a single collision — effectively impossible in practice.
GUID (Globally Unique Identifier) is Microsoft's name for the same concept. Both follow RFC 4122 and are completely interchangeable. .NET uses GUID, most other platforms use UUID.
Yes, but v4 UUIDs are random and cause index fragmentation in B-tree indexes. For high-insert databases, prefer UUID v7 (time-ordered) or ULID which sort chronologically and are more index-friendly.
In 2026, if you’re choosing a new UUID format for database keys, prefer UUIDv7 over random UUIDv4 when your stack supports it. UUIDv7 keeps the same 128-bit size but starts with a timestamp, so new rows insert in near-sorted order instead of scattering across indexes. That usually means smaller index fragmentation and better write performance in PostgreSQL, MySQL, and SQLite. Common mistake: generating v4 everywhere by habit, then wondering why primary-key indexes bloat. Keep v4 for pure randomness needs; use v7 for ordered IDs.