UUID Generator

What is a UUID?

A UUID (Universally Unique Identifier, RFC 4122 / RFC 9562) is a 128-bit identifier created without any central authority, yet practically globally unique. The text form is 32 hex digits, separated into five groups `8-4-4-4-12` by hyphens, totalling 36 characters including separators.

Several versions exist. v1 uses time + MAC address (privacy concern), v3 and v5 derive the ID from a name plus namespace (deterministic), v4 is purely random (the modern default), and v7 is time-ordered and addresses the database-index problem of v4.

Alongside those, ULID and NanoID are popular non-IETF alternatives. ULID is a 26-character sortable string, NanoID a short URL-safe ID (often 21 characters). Which variant fits depends primarily on the planned storage and URL layout.

v4 vs. v7 vs. ULID vs. NanoID

A quick overview of the four most important variants:

Crockford base32 (ULID) drops I, L, O and U to avoid confusion with 1, 0 and V.

When do I pick which variant?

Rules of thumb from real-world use:

• UUID v4: solid default for non-sorted IDs (sessions, idempotency keys, correlation IDs). 122 bits of entropy, collision probability absurdly low.
• UUID v7: recommended for database primary keys. The first 48 bits are a unix-ms timestamp, so new rows go to the tail of B-tree indexes (low page-split pressure, good locality).
• ULID: when you want a time-ordered ID that stays readable in URLs and logs. 26 characters, shorter than UUID, but not an RFC standard. Some tooling stacks lack native support.
• NanoID-21: ideal for user-facing share links and slugs. 21 characters, URL-safe, around 126 bits of entropy (more than UUID v4) at a much shorter length.

Why not auto-increment IDs in production?

Auto-increment IDs (e.g. `BIGINT IDENTITY` or `SERIAL`) are simple, fast and index-friendly, but they fail several modern requirements:

• They leak business metrics: a competitor seeing two consecutive order numbers immediately learns roughly how many orders flow per day.
• They give no bot protection: `/users/123` is what every brute-force crawler walks from 1 to n, every ID is trivially enumerable.
• They hinder distributed systems: a multi-region setup or offline clients (mobile apps, edge) need to coordinate sequences or run a central ID service. UUIDs avoid that entirely.
• They cannot be assigned client-side: a frontend cannot reserve an auto-increment ID before the INSERT (e.g. for optimistic UI). UUIDs are generated in the client and passed through the `INSERT`.
• They are not test-friendly: tests that roll back data collide with sequence values or leave gaps. UUIDs stay stable across tests.

Recommendation: keep auto-increment for internal, purely operational tables (migration log, counters), and use UUID v7 as the default primary key for domain entities (User, Order, Document).

UUID performance in databases

The most common objection against UUIDs is "they wreck index performance". That used to be partly true, but it is either easily fixed or fully avoided with v7/ULID.

The real issue is not the size (16 bytes vs. 8 bytes for a bigint), but the random-insert order: with v4, every insert lands somewhere in the middle of the B-tree, causing page splits, cold caches and write amplification.

• Solution 1: use UUID v7 or ULID instead of v4. The time-ordered bits ensure new rows go to the tail of the index.
• Solution 2: in PostgreSQL use the `uuid` type, in MySQL `BINARY(16)` (instead of `CHAR(36)`), saving 20 bytes per row and making comparisons integer-fast.
• Solution 3: place the clustered index on a different key (e.g. monotonically increasing) and keep the UUID as a secondary key. Common in MS SQL Server.
• Solution 4: for bulk inserts, insert in sorted order, or use a bulk loader that rebuilds the index at the end.

On recent Postgres and MySQL versions, UUID v7 as primary key is faster than v4 in nearly every workload and roughly on par with bigint auto-increment, while keeping all benefits (no leak, distributed creation, client-side).

High-throughput backends at KernelHost

If you store millions of UUIDs per day in a database, you want NVMe storage, ECC RAM and a stable uplink. KernelHost runs its own dedicated and VPS servers in Frankfurt FRA01 with DDoS protection, IPv4 + IPv6 and 1 Gbit/s. Low RTT to German and Austrian customers, fair pricing. Company seat Vienna (AT), data center Frankfurt (DE).

UUID FAQ