UUIDs as Database Primary Keys

Should you use UUID v4 or UUID v7 as a primary key? See how each version affects index locality, and generate sample keys.

Part of the free UUID Generator. Runs in your browser — nothing is uploaded.

UUIDs as Database Primary Keys

Random UUID v4 keys scatter inserts across a B-tree, which can bloat indexes. UUID v7 keeps new rows near the end of the index because the timestamp prefix increases over time. Generate both and pick the one that matches your store.

Worked example: v4 vs v7 for a primary key

Candidates

v4: 550e8400-e29b-41d4-a716-446655440000
v7: 018d5f8a-7c3b-7a21-8f4c-2e9b1a0c5d77

Analysis

✓ Valid UUID
Version: 4 — random
Variant: RFC 9562 (10xx)

✓ Valid UUID
Version: 7 — Unix-epoch time-ordered
Variant: RFC 9562 (10xx)
Embedded timestamp: 2024-01-31T12:42:07.803Z

Practical tip

In Postgres use the native uuid type, not varchar(36). It stores 16 bytes and compares faster.

How to use this UUID Generator

  1. 1Use the live tool above — it runs entirely in your browser and never uploads your data.
  2. 2Paste the sample from the worked example, or use your own input.
  3. 3Copy the result, then adapt the same steps in your editor, script, or pipeline.

UUIDs as Database Primary Keys FAQs

Is UUID better than a bigserial primary key?

UUIDs are better when IDs must be created in many services without a central counter. Sequential integers are smaller and faster when a single database issues them.

Can I use UUID v4 as a primary key anyway?

Yes, many systems do. Expect more page splits and a larger index than with v7 or a sequence.