UUID Best Practices: Version Choice, Storage, and Indexing for Developers

UUIDs are everywhere in modern backends, but how you use them matters as much as whether you use them. A UUID generated the wrong way — or stored the wrong way — can bloat your database and slow your queries. This guide covers the practical decisions: which version to generate, how to store it, and how to keep indexes fast.

Which UUID Version Should You Generate?

Version	How It Works	Best For
UUID v4	122 random bits	Simple, collision-resistant IDs; the default for most apps
UUID v7	Time-ordered + random bits	Database primary keys; sequential-friendly inserts
UUID v1	Timestamp + MAC address	Legacy systems; avoid for new work (leaks MAC and time)
UUID v3/v5	Hash of a namespace + name	Deterministic IDs from known strings (e.g., deduplication)

For new projects, v4 is the safe default and v7 is the best choice when the UUID is a primary key in a database that indexes by value order. If you need to create one right now, use the free UUID generator on todaycalculator.com.

Storage: Binary(16) Beats Char(36)

A UUID string like 550e8400-e29b-41d4-a716-446655440000 looks like 36 characters, but it is really 16 bytes. Storing it as CHAR(36) uses more than twice the space of BINARY(16), and every comparison has to work through the dashes and hex encoding.

• MySQL / PostgreSQL: store as BINARY(16) or the native UUID type and convert in the application layer.
• SQL Server: use uniqueidentifier.
• Application code: convert the 36-char string to 16 bytes before insert, and back to string when reading.

Index Fragmentation: The Hidden Cost of Random UUIDs

Random values (v4) inserted into a B-tree index land in random positions, forcing page splits and cache misses as the table grows. This is why UUID primary keys earned a reputation for being slow. Time-ordered UUIDs (v7) fix the problem by sorting chronologically, so new rows append near the end of the index.

If you already have a v4 primary key and see index bloat, options are: switch new rows to v7 (mixed keys work, with a migration cost), or keep v4 but store as binary and tune the buffer pool.

When NOT to Use UUIDs

• Small, single-server apps: auto-increment integers are smaller, faster, and easier to debug.
• Human-facing identifiers: long random strings are terrible in URLs and support tickets — use short slugs.
• When order matters to users: if “newest first” is a business rule, a sequential ID may be simpler than parsing timestamps out of UUIDs.

The bottom line: generate v4 or v7, store as 16 bytes, and match the version to your indexing strategy. For quick testing and one-off IDs, the UUID generator tool gives you clean v4 UUIDs instantly.