UUID

UUIDs come in several versions, each designed for specific use cases. UUID v1 combines a timestamp with the MAC address of the generating machine, making it unique but potentially exposing hardware information. UUID v3 and v5 are namespace-based, generating deterministic identifiers by hashing a namespace and name using MD5 or SHA-1 respectively.

UUID v4 remains the most widely used version, generating completely random identifiers with 122 bits of randomness. For modern applications, UUID v7 (introduced in RFC 9562) offers the best of both worlds: a Unix timestamp prefix for natural sorting combined with random bits for uniqueness. This makes v7 ideal for database primary keys where index performance matters.

While UUIDs are the industry standard, ULIDs (Universally Unique Lexicographically Sortable Identifiers) offer some advantages. ULIDs are case-insensitive, use a more compact encoding (26 characters vs 36 for UUIDs), and are naturally sortable by creation time.

Choose UUID v7 if you need maximum compatibility with existing systems and libraries. Choose ULID if you want shorter identifiers and your stack supports them. Both are excellent choices for distributed systems where coordination-free ID generation is required.

When using UUIDs as primary keys, consider these performance tips:

• Use UUID v7 or ULID for better index locality due to their time-ordered nature
• Store UUIDs as BINARY(16) instead of VARCHAR(36) to save storage space
• Consider using UUID v4 for security-sensitive contexts where predictability must be avoided
• In PostgreSQL, use the native UUID type for optimal performance