Which UUID version is generated?

Version 4, from a cryptographically secure random source, per RFC 4122.

Should I use UUIDs as primary keys?

They avoid coordination between services, but random v4 values scatter writes across a B-tree index. For high write volumes consider a time-ordered identifier such as UUIDv7 or ULID.

UUID v4 Generator

A UUID generator produces RFC 4122 version 4 identifiers from a cryptographically secure random source.

Version 4 UUIDs are 122 bits of randomness with the version and variant bits set. They are generated with the platform crypto API, so they are suitable for database primary keys, idempotency keys and correlation identifiers in tests.

Options

Name	Type	Default	Description
`count`	integer	`5`	How many records to return, from 1 to 1000.

Use cases

Database keys: Seed tables that use UUID primary keys.
API fixtures: Produce stable-looking identifiers for mocked API responses.
Correlation IDs: Generate request identifiers for tracing experiments.

REST API

GET /api/v1/uuid

curl "https://ukaddressgenerator.org/api/v1/uuid?count=5"

{ "status": "success", "count": 1, "version": "v4", "data": ["b4c0f4b2-1f8e-4f7c-9c1a-7f1a2b3c4d5e"] }

Frequently asked questions

Which UUID version is generated?: Version 4, from a cryptographically secure random source, per RFC 4122.
Should I use UUIDs as primary keys?: They avoid coordination between services, but random v4 values scatter writes across a B-tree index. For high write volumes consider a time-ordered identifier such as UUIDv7 or ULID.

UUIDs as identifiers

Version 4, index behaviour and when to choose something else · 150 words

1. What a version 4 UUID is

A v4 UUID is 122 bits of randomness with six bits fixed for the version and variant. Collisions are not a practical concern: you would need to generate billions per second for many years before the probability became meaningful.

2. The index cost

Because v4 values are random, consecutive inserts land in random positions in a B-tree index. That fragments pages and hurts write throughput on large, high-volume tables. Sequential integers do not have this problem, but require coordination.

3. Choosing an identifier

For most applications a v4 UUID is fine. For write-heavy tables consider a time-ordered identifier such as UUIDv7 or ULID, which keeps insert locality while remaining generated client-side. If you expose identifiers publicly, a random one avoids leaking record counts.

curl "/api/v1/uuid?count=5"