UUID v1 vs UUID v4
Both UUID v1 and v4 produce a 128-bit identifier in the same 8-4-4-4-12 hex format, but they generate that identifier very differently. The choice between them affects sortability, privacy, and database index performance.
UUID v1 is time-based and sortable; UUID v4 is randomly generated. Compare their structure, privacy implications, database performance, and when to use each.
UUID v1 (time-based)
Open UUID v1 (time-based) →UUID v1 combines the current timestamp (100-nanosecond intervals since October 1582) with a clock sequence and node identifier (typically a MAC address or random value). UUIDs generated close together will have similar prefixes.
Use cases
- Database primary keys where insertion order and index locality matter
- Distributed systems where creation time is useful metadata
- Event sourcing and audit logs where chronological ordering is important
- Cassandra and other distributed databases that are optimised for time-ordered UUIDs
Strengths
- Sortable by creation time — newer UUIDs sort after older ones
- Better database index performance for sequential inserts (less page splitting)
- Encodes creation time, which can be useful for debugging
Limitations
- Leaks the MAC address and creation timestamp — a privacy concern
- Two UUIDs generated at the same millisecond on the same node are predictable
- MAC address exposure can reveal device identity in multi-tenant systems
UUID v4 (random)
Open UUID v4 (random) →UUID v4 uses 122 bits of cryptographically secure random data. The remaining 6 bits are fixed version and variant markers. There is no time or node component — each UUID is completely independent of when and where it was generated.
Use cases
- General-purpose unique identifiers where privacy and unpredictability are required
- Session tokens, API keys, and idempotency tokens
- Identifiers in systems where exposing creation time or node identity is undesirable
- Most web application use cases — the safe default choice
Strengths
- No personally identifiable information leaked (no MAC address, no timestamp)
- Completely unpredictable — cannot be guessed or enumerated
- Simple to generate correctly in any language or environment
Limitations
- Random distribution causes index fragmentation in B-tree databases at scale
- Does not encode creation time — you need a separate created_at column
- Slightly worse database insert performance than sequential IDs at very high volume
Default to UUID v4 for most web application use cases — it is simple, private, and unpredictable. Use UUID v1 (or the newer UUID v7, which uses a Unix millisecond timestamp instead of the 1582 epoch) when you need sortable identifiers for better database index performance, and when leaking a creation timestamp is acceptable. Never use UUID v1 if exposing a MAC address is a concern.
Do UUID collisions actually happen in practice?
UUID v4 collisions are astronomically unlikely. With 122 random bits, you would need to generate approximately 2.71 quintillion UUIDs before the probability of any collision reached 50%. For any real-world application, UUIDs can be treated as globally unique without a central coordinator.
What is UUID v7 and should I use it?
UUID v7 is a newer standard (RFC 9562) that uses a Unix millisecond timestamp in the most significant bits, making it sortable like v1 but without the MAC address privacy concern. It combines the sortability of v1 with the privacy of v4 and is increasingly supported by databases and ORMs. For new projects that need sortable UUIDs, v7 is the better choice over v1.
Does UUID format matter for database primary keys?
Yes, significantly at scale. Random UUIDs (v4) cause B-tree index fragmentation because new rows are inserted at random positions. At millions of rows, this causes page splits and extra disk I/O. Sequential identifiers (UUID v1, UUID v7, or ULID) insert at the end of the index, dramatically reducing fragmentation. For most applications below a few million rows, the difference is negligible.
Base64 vs URL Encoding
Base64 and URL encoding both transform data into a safe text format, but they serve different purposes. Learn when to use each, how they differ, and which to choose for your use case.
JSON vs YAML
JSON and YAML both represent structured data but differ in syntax, readability, and use cases. Compare them side by side to decide which format suits your configuration files and APIs.
MD5 vs SHA-256
MD5 and SHA-256 are both cryptographic hash functions, but SHA-256 is far more secure. Compare their output length, speed, collision resistance, and when each is appropriate to use.