← Back to Blog

Understanding UUIDs: A Developer's Complete Guide

UUIDs (Universally Unique Identifiers) are 128-bit numbers used to uniquely identify information in computer systems. They're essential in distributed systems, microservices, and modern databases where generating unique IDs without central coordination is critical.

What is a UUID?

A UUID is a 128-bit (16-byte) number, typically displayed as 36 characters in this format:

550e8400-e29b-41d4-a716-446655440000

The format is: 8 characters - 4 - 4 - 4 - 12 characters, all hexadecimal (0-9, a-f).

Why Use UUIDs?

1. No Central Coordination

Generate IDs anywhere without checking a central database. Perfect for distributed systems where multiple servers create records simultaneously.

2. Collision Resistance

The probability of generating duplicate UUIDs is astronomically low. With 2^122 possible UUIDs (version 4), you can generate a billion UUIDs per second for 100 years before having a 50% chance of collision.

3. Non-Sequential

Unlike auto-incrementing integers, UUIDs don't reveal information about record count or creation order. This improves security by making IDs unpredictable.

4. Database-Agnostic

UUIDs work across any database system. Move data between PostgreSQL, MySQL, MongoDB, or DynamoDB without ID conflicts.

UUID Versions

Version 1: Timestamp + MAC Address

Generated from current timestamp and machine MAC address.

• ✅ Sortable by time
• ❌ Reveals machine identity and creation time
• ❌ Privacy concerns
• ❌ Rarely used today

Version 4: Random (Most Popular)

Generated using random or pseudo-random numbers.

• ✅ Simple to generate
• ✅ Privacy-friendly
• ✅ No coordination needed
• ✅ Most widely used
• ❌ Not sortable by creation time

// JavaScript
const uuid = crypto.randomUUID();
// Output: 9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d

// Python
import uuid
uuid_str = str(uuid.uuid4())

// Java
import java.util.UUID;
UUID uuid = UUID.randomUUID();

🆔 Generate UUIDs Instantly →

Version 5: Namespace + Name (SHA-1)

Generated from namespace and name using SHA-1 hash. Same inputs always produce same UUID.

• ✅ Deterministic (reproducible)
• ✅ Useful for creating IDs from existing data
• ❌ More complex to implement

When to Use UUIDs

Perfect Use Cases

• Distributed databases: Multiple servers generating IDs independently
• Microservices: Each service creates its own IDs without conflicts
• Public-facing IDs: API endpoints, URLs (/users/550e8400-e29b-41d4-a716-446655440000)
• Offline data generation: Mobile apps creating records while offline
• Multi-tenant systems: Prevent ID collisions between tenants
• Merge operations: Combining data from multiple sources

When NOT to Use UUIDs

• Small datasets: Integer IDs are simpler and smaller
• User-facing IDs: Too long for humans to type or remember
• High-performance requirements: Larger index sizes can impact speed
• Sequential ordering matters: UUIDs don't provide natural ordering

Performance Considerations

Storage Size

UUIDs are 128 bits (16 bytes) vs 32-64 bits for integers:

INTEGER     : 4 bytes
BIGINT      : 8 bytes
UUID        : 16 bytes (4x larger than INTEGER)

Impact on 1M records:
- INTEGER: 4 MB
- UUID: 16 MB

Index Performance

Random UUIDs cause B-tree fragmentation in databases, slowing inserts. Solutions:

• UUIDv7: New standard with timestamp prefix for better indexing
• Binary storage: Store as BINARY(16) instead of VARCHAR(36) to save space
• Separate ID column: Use auto-increment for primary key, UUID for public ID

Database Implementation

PostgreSQL

-- Native UUID type
CREATE TABLE users (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    username VARCHAR(255)
);

-- Insert
INSERT INTO users (username) VALUES ('john');

-- Query
SELECT * FROM users WHERE id = '550e8400-e29b-41d4-a716-446655440000';

MySQL

-- Binary storage for efficiency
CREATE TABLE users (
    id BINARY(16) PRIMARY KEY,
    username VARCHAR(255)
);

-- Insert (requires function to convert)
INSERT INTO users (id, username) 
VALUES (UUID_TO_BIN(UUID()), 'john');

-- Query
SELECT BIN_TO_UUID(id), username FROM users;

MongoDB

// MongoDB uses ObjectId by default (12 bytes)
// But you can use UUIDs
const { v4: uuidv4 } = require('uuid');

db.users.insertOne({
    _id: uuidv4(),
    username: 'john'
});

Best Practices

1. Use Standard Libraries

Don't implement UUID generation yourself. Use battle-tested libraries:

• JavaScript: crypto.randomUUID() or uuid npm package
• Python: uuid standard library
• Java: java.util.UUID
• Go: github.com/google/uuid

2. Store as Binary in Databases

VARCHAR(36) wastes space. Binary(16) saves 44% storage and improves performance.

3. Add Indexes on UUID Columns

CREATE INDEX idx_user_id ON orders(user_id);

4. Use UUIDv4 Unless You Have Specific Needs

Version 4 is simple, secure, and widely supported. Use v1 only if you need time-based sorting, v5 for deterministic generation.

5. Validate UUIDs

Always validate UUID format in API inputs:

// JavaScript validation
function isValidUUID(str) {
    const regex = /^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i;
    return regex.test(str);
}

UUID vs Auto-Increment vs ULID

Auto-Increment Integers

• ✅ Small, fast, simple
• ✅ Natural ordering
• ❌ Requires central coordination
• ❌ Reveals record count

UUID

• ✅ Decentralized generation
• ✅ Globally unique
• ❌ Larger storage
• ❌ Random ordering (v4)

ULID (Universally Unique Lexicographically Sortable Identifier)

• ✅ Sortable by time
• ✅ More compact than UUID when Base32 encoded
• ✅ Compatible with UUID
• ❌ Less widely supported

Common Pitfalls

1. Using UUIDs as User-Facing IDs

36 characters is too long for users to type. Use short codes for customer-facing IDs.

2. Not Planning for Index Bloat

Random UUIDs fragment indexes. Monitor database performance and consider UUIDv7 or ULID.

3. Comparing UUIDs as Strings

Store and compare as binary for better performance.

Tools and Resources

Need UUIDs right now? Our UUID Generator creates RFC-compliant version 4 UUIDs instantly. Generate one or thousands with a single click.

Conclusion

UUIDs are essential for modern distributed systems. They eliminate coordination overhead, prevent ID collisions, and work seamlessly across databases and services. While they have trade-offs in storage size and performance, the benefits usually outweigh the costs in scalable applications.

Choose UUIDv4 for most use cases, store them efficiently, and enjoy the freedom of decentralized ID generation.

← Back to Blog