UUID Guide: Versions, Formats, and When to Use Each

UUIDs (Universally Unique Identifiers) are 128-bit identifiers used everywhere — database primary keys, API request IDs, session tokens, distributed system message IDs. But not all UUIDs are created equal. There are multiple versions with different generation methods, performance characteristics, and use cases.

What Is a UUID?

A UUID is a 128-bit number displayed as 32 hexadecimal characters in five groups separated by hyphens:

550e8400-e29b-41d4-a716-446655440000
^^^^^^^^ ^^^^ ^^^^ ^^^^ ^^^^^^^^^^^^
   8      4    4    4       12       = 32 hex chars

Format: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
M = version digit (1, 4, 7, etc.)
N = variant digit (8, 9, a, or b)

The version is encoded in the 13th character (the M position). So you can identify a UUID's version by looking at that digit: 550e8400-e29b-41d4-... is a v4 UUID.

UUID Versions Explained

UUID v1 — Timestamp + MAC Address

V1 UUIDs combine a 60-bit timestamp (100-nanosecond intervals since October 15, 1582) with the machine's MAC address:

// Example v1 UUID:
6fcb514b-b878-1100-8998-00163e3a2d5c
                ^                    ← version 1

• Pro: Naturally sortable by creation time. Guaranteed unique across machines (different MACs).
• Con: Leaks the machine's MAC address and creation timestamp — a privacy concern.
• Use case: Largely superseded by v7. Avoid for new projects.

UUID v4 — Random

V4 UUIDs are generated from 122 bits of random data (6 bits are used for version and variant):

// Example v4 UUID:
f47ac10b-58cc-4372-a567-0e02b2c3d479
                ^                    ← version 4

• Pro: Simple, no external dependencies, no privacy concerns. The probability of collision is astronomically low — you'd need to generate 2.71 × 10^18 UUIDs to have a 50% chance of one collision.
• Con: Not sortable by time. Random distribution causes poor database index performance — inserts scatter across B-tree pages, causing fragmentation.
• Use case: General-purpose unique IDs where sort order doesn't matter.

UUID v7 — Timestamp + Random (The Modern Choice)

V7 is the newest version (RFC 9562, 2024) and the best choice for most applications:

// Example v7 UUID:
018e4a6e-5c3a-7b12-8f1e-4a3b2c1d0e0f
                ^                    ← version 7

Structure:
| 48-bit Unix timestamp (ms) | 4-bit version | 12-bit random | 2-bit variant | 62-bit random |

• Pro: Time-sortable (lexicographic order = chronological order), excellent database index performance, no privacy leaks. Combines the best of v1 and v4.
• Con: Newer, so not all libraries support it yet.
• Use case: Database primary keys, event IDs, anything that benefits from chronological ordering.

UUID v4 vs v7: Database Performance

This is the most important practical difference. In a B-tree index (used by PostgreSQL, MySQL, SQLite):

Metric	UUID v4 (Random)	UUID v7 (Time-sorted)
Insert performance	Degrades as table grows	Consistent (append-only)
Index fragmentation	High (random page splits)	Low (sequential inserts)
Cache efficiency	Poor (random access pattern)	Excellent (hot pages stay cached)
Range queries by time	Requires separate timestamp column	Built-in (just query the UUID range)

Benchmarks consistently show v7 UUIDs providing 2-10x better insert performance than v4 in indexed database columns at scale. If you're using UUIDs as primary keys, v7 is the right choice.

Generating UUIDs

JavaScript / Node.js

// Built-in (v4) — available in browsers and Node.js
const id = crypto.randomUUID();
// "f47ac10b-58cc-4372-a567-0e02b2c3d479"

// Using the 'uuid' package (v4 and v7)
import { v4 as uuidv4, v7 as uuidv7 } from 'uuid';
const id4 = uuidv4();  // random
const id7 = uuidv7();  // time-sorted

Python

import uuid

# v4 (random)
id4 = uuid.uuid4()
# UUID('f47ac10b-58cc-4372-a567-0e02b2c3d479')

# v1 (timestamp + MAC)
id1 = uuid.uuid1()

# v7 (Python 3.14+)
# id7 = uuid.uuid7()

# For v7 on older Python, use the uuid7 package:
# pip install uuid7
# import uuid7
# id7 = uuid7.uuid7()

PostgreSQL

-- v4 (built-in since PostgreSQL 13)
SELECT gen_random_uuid();

-- v7 (PostgreSQL 17+)
SELECT uuidv7();

-- Using as primary key
CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL
);

Command Line

# macOS / Linux
uuidgen

# Python one-liner
python3 -c "import uuid; print(uuid.uuid4())"

UUIDs vs Other ID Formats

Format	Length	Sortable	Use Case
Auto-increment	Variable	Yes	Single-database apps
UUID v4	36 chars	No	General-purpose distributed IDs
UUID v7	36 chars	Yes	Database PKs, distributed systems
ULID	26 chars	Yes	Compact, Crockford Base32 encoded
Snowflake ID	~19 digits	Yes	High-throughput systems (Twitter, Discord)
nanoid	21 chars	No	URL-safe, compact random IDs

Storing UUIDs in Databases

• PostgreSQL: Use the native UUID type — stored as 16 bytes internally, with built-in indexing support.
• MySQL: Use BINARY(16) with UUID_TO_BIN() for optimal storage, or CHAR(36) for readability at the cost of 2.25x more storage.
• SQLite: Store as TEXT (no native UUID type) or as a 16-byte BLOB.
• MongoDB: MongoDB's ObjectId is already time-sorted — consider using it instead of UUIDs.

FAQ

Can UUIDs collide?

Theoretically yes, practically no. For UUID v4, you'd need to generate 103 trillion UUIDs to have a one-in-a-billion chance of a single collision. Your database has other problems at that scale.

Are UUIDs secure?

UUID v4 uses cryptographically secure random numbers and is suitable for security-sensitive identifiers. UUID v1 leaks timestamps and MAC addresses. UUID v7 leaks creation time but not machine identity. For secret tokens, consider using a cryptographically random string instead.

Should I use UUIDs as primary keys?

Yes, but prefer UUID v7 over v4 for indexed columns. V7's time-sorted nature avoids the B-tree fragmentation issues that make v4 slow at scale. If you need compact IDs visible to users, consider ULID or nanoid instead.

Need to quickly generate UUIDs for testing or development? Our UUID Generator creates both v4 and v7 UUIDs instantly in your browser, with options for bulk generation and different formats.