UUID vs Auto-Increment IDs: Which Should You Use?

What Is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit value designed to be globally unique without requiring a central authority. Defined in RFC 4122, UUIDs are represented as 32 hexadecimal digits separated by hyphens in five groups:

550e8400-e29b-41d4-a716-446655440000
|        |    |    |    |
|        |    |    |    +-- Node (48 bits)
|        |    |    +------- Clock Seq (16 bits)
|        |    +------------ Version (4 bits) + Time Mid
|        +----------------- Time Low (32 bits)
+-------------------------- Full UUID (128 bits / 36 chars)

The total number of possible UUIDs is 2¹²⁸ (approximately 3.4 x 10³⁸). To put that in perspective, you could generate one billion UUIDs per second for 100 years and the probability of a collision would still be astronomically small. This mathematical guarantee is what makes UUIDs suitable for distributed systems where coordination between nodes is impractical.

Auto-increment IDs, on the other hand, are sequential integers managed by the database engine. Each new row gets the previous maximum value plus one. They are simple, compact, and fast — but they come with limitations that become apparent at scale.

UUID Versions Compared

Not all UUIDs are created equal. The version number (the 13th character) determines how the UUID is generated. Here is how the main versions differ:

UUID v4 — The Most Popular

UUID v4 is generated using 122 bits of random data (6 bits are reserved for version and variant). It is the default choice in most libraries and frameworks. The randomness means there is no embedded information — no timestamps, no node identifiers, and no way to predict the next value.

UUID v7 — The Modern Choice

UUID v7 was introduced in the 2024 update to RFC 9562. It embeds a millisecond-precision Unix timestamp in the most significant 48 bits, followed by random data. This means UUIDs generated later are lexicographically larger, making them naturally sortable and B-tree friendly. UUID v7 combines the uniqueness of UUIDs with the indexing performance of sequential IDs.

UUID vs Auto-Increment: Pros and Cons

UUIDs in Distributed Systems

Distributed systems are where UUIDs truly shine. When you have multiple application servers, microservices, or database replicas that all need to create records independently, auto-increment IDs become a bottleneck. You either need a centralized ID service (single point of failure) or pre-allocated ID ranges (complex to manage).

With UUIDs, every node can independently generate identifiers with virtually zero collision risk. This enables patterns like:

• Offline-first applications — Mobile or desktop apps can create records while offline and sync later without ID conflicts
• Event sourcing — Events can be generated by any service and merged into a single stream
• Multi-region databases — Each region writes independently without cross-region coordination
• Microservice communication — Services can reference entities created by other services before they are persisted
• Database merging — Combining data from multiple databases (e.g., after an acquisition) without remapping IDs

Database Performance Impact

The biggest concern with UUIDs as primary keys is their impact on database performance, particularly with random UUID v4. Here is why:

• B-tree fragmentation: Random UUIDs cause inserts to land on random pages in the B-tree index. This leads to page splits, increased write amplification, and poor cache utilization. In high-throughput scenarios, this can degrade write performance by 30-50% compared to sequential IDs.
• Larger index size: A UUID (16 bytes) is 2-4x larger than an integer (4-8 bytes). Every secondary index that references the primary key stores a copy, so the storage overhead compounds across indexes.
• Poor locality: Random IDs mean related records are scattered across disk pages, reducing the effectiveness of buffer pool caching.

Alternatives: ULID and NanoID

ULID (Universally Unique Lexicographically Sortable Identifier)

ULID is a 128-bit identifier that encodes a 48-bit millisecond timestamp followed by 80 bits of randomness. It is encoded as a 26-character Crockford Base32 string, making it shorter than a UUID and case-insensitive. ULIDs are monotonically sortable and URL-safe.

01ARZ3NDEKTSV4RRFFQ69G5FAV  // ULID (26 chars)
550e8400-e29b-41d4-a716-446655440000  // UUID (36 chars)

NanoID

NanoID is a tiny, URL-friendly unique string ID generator. It uses a customizable alphabet and length (default 21 characters with URL-safe characters). NanoID is not a 128-bit standard like UUID — it is a practical alternative when you need short, random, URL-safe identifiers for things like short URLs, session tokens, or file names.

V1StGXR8_Z5jdHi6B-myT  // NanoID (21 chars)

UUID Generation in Every Language

JavaScript / Node.js

// Built-in (Node 19+ / modern browsers)
const id = crypto.randomUUID();
// "3b241101-e2bb-4d7a-8702-9e5e8a6b0c1a"

// Using the uuid package
import { v4 as uuidv4, v7 as uuidv7 } from 'uuid';
const id4 = uuidv4();  // Random UUID v4
const id7 = uuidv7();  // Time-ordered UUID v7

Python

import uuid

id4 = uuid.uuid4()          # Random UUID v4
id5 = uuid.uuid5(            # Deterministic UUID v5
    uuid.NAMESPACE_DNS,
    "example.com"
)
print(str(id4))  # "a3bb189e-8bf9-3888-9912-ace4e6543002"

Go

import "github.com/google/uuid"

id := uuid.New()        // UUID v4
id7, _ := uuid.NewV7()  // UUID v7
fmt.Println(id.String())

Java

import java.util.UUID;

UUID id = UUID.randomUUID();  // UUID v4
System.out.println(id.toString());
// "550e8400-e29b-41d4-a716-446655440000"

PostgreSQL

-- UUID v4 (all versions)
SELECT gen_random_uuid();

-- UUID v7 (PostgreSQL 17+)
SELECT gen_random_uuid_v7();

-- As a primary key
CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

When to Choose UUID vs Auto-Increment

Choose UUID When

• You are building a distributed system or microservices architecture
• IDs need to be generated client-side or before persisting to the database
• You are exposing IDs in public URLs or APIs and do not want them to be guessable
• You need to merge data from multiple databases
• Your application supports offline mode with later synchronization

Choose Auto-Increment When

• You have a single database with no plans for sharding
• Storage efficiency is critical (IoT, embedded systems, billions of rows)
• You need IDs that are easy to reference in conversations or support tickets
• You are working with legacy systems that expect integer foreign keys
• You need maximum insert performance and are not using UUID v7