A UUID (Universally Unique Identifier) is a special 128-bit value that helps you identify something in a system so that no two items ever get the same ID. You can think of it as a super long number that is almost impossible to repeat, even if thousands of different systems generate them at the same time.

UUIDs are used everywhere: in databases, APIs, distributed systems, mobile apps, and even when you create files on your computer. Their main purpose is simple - give every object a unique ID without asking any other system for permission.

Why Do We Need UUIDs?

Imagine you work on a project with many services:

one service creates user accounts
another service processes payments
a mobile app creates local data
a backend saves objects in a database

If all these services generate IDs independently, there is a high chance of duplicates if you use something like simple numbers (1, 2, 3…). To avoid this, you need a type of ID that is unique globally.

This is exactly what UUIDs solve

No central server needed
No coordination required
Very small chance of collision (almost zero)

This makes UUIDs perfect for distributed systems.

How Does a UUID Look?

A UUID is 128 bits long, but usually you see it as a 36-character string:

example

166e69275-c6bc-800c-90a6-2f41cb991502

Its structure follows the pattern:

pattern

18-4-4-4-12

This means:

8 hex characters
then 4
then 4
then 4
then 12

The hyphens are only for readability.

Versions of UUID

UUIDs come in multiple versions. The version defines how the UUID is generated.

Version 1 – based on timestamp + MAC address

Generated using:

current time
your computer’s MAC address

This makes it unique, but sometimes developers avoid it because it reveals hardware information.

Example:

example

1f47ac10b-58cc-11e8-b623-0800200c9a66

Here:

11e8 indicates version 1
the last part contains MAC-related data

Version 4 – completely random

The most popular version today. It uses random numbers.

example

166e69275-c6bc-800c-90a6-2f41cb991502

It is very unlikely to repeat. There are about 5.3 × 10^36 possible UUIDs.

Other versions

There are also:

Version 3 and 5 - generated using hashing and a namespace (useful for deterministic IDs)
Version 7 - new timestamp-based format designed for better sorting

For most modern projects, Version 4 and Version 7 are the most common choices.

UUID Variants

Variants define how the bits are arranged. The most used is Variant 1, defined in RFC 4122. This is also what Microsoft GUIDs follow.

Choosing the Right UUID Version

Not all UUIDs are created equal. Different versions serve different purposes:

Quick Decision Guide

UUID v7 - Best for most use cases (time-ordered, database-friendly)
UUID v4 - When you need maximum unpredictability
ULID - Great alternative with better readability

The best architecture is the one that postpones decisions about databases, frameworks, and external dependencies until the last possible moment.
— Martin Fowler, Chief Scientist at ThoughtWorks

Database Storage Optimization

How you store UUIDs in your database significantly impacts performance and storage costs.

Store as Binary, Not String

schema.sql

1-- ❌ Bad: Storing as VARCHAR(36)
2CREATE TABLE users (
3    id VARCHAR(36) PRIMARY KEY,  -- 36 bytes + overhead
4    name VARCHAR(255)
5);
6 
7-- ✅ Good: Storing as BINARY(16)
8CREATE TABLE users (
9    id BINARY(16) PRIMARY KEY,   -- 16 bytes
10    name VARCHAR(255)
11);
12 
13-- MySQL example with UUID functions
14INSERT INTO users (id, name)
15VALUES (UUID_TO_BIN(UUID()), 'John Doe');
16 
17SELECT BIN_TO_UUID(id), name FROM users;

Storage Savings

Storing UUIDs as BINARY(16) instead of VARCHAR(36) saves 55% storage space and improves index performance significantly.

Index Strategy

With UUID v7's time-based ordering, you can create efficient indexes without fragmentation:

Type Safety Tip

Branded types prevent accidentally using the wrong UUID type, catching bugs at compile time rather than runtime.

3. Handle UUID Generation Failures

Common Pitfalls to Avoid

Critical Mistakes

❌ Using client-generated UUIDs without validation - Always validate on the server
❌ Storing UUIDs as strings in production - Use BINARY(16) for efficiency
❌ Using UUID v1 - Exposes MAC address; use v7 instead
❌ Not considering timezone issues with v7 - Always use UTC timestamps
❌ Mixing UUID versions in same table - Stick to one version per use case

Migration Strategy

If you're migrating from another ID system to UUIDs, follow this approach:

Key Takeaways

✅ Use UUID v7 for most production use cases
✅ Store UUIDs as BINARY(16) in databases
✅ Implement proper validation and error handling
✅ Use TypeScript branded types for type safety
✅ Monitor UUID generation and validate performance
✅ Plan migrations carefully with dual-write strategies

How to Generate a UUID in Different Languages

Javascript

index.js

1import { v4 as uuidv4 } from 'uuid';
2 
3const id = uuidv4();
4console.log(id);

main.go

1import "github.com/google/uuid"
2 
3id := uuid.New()
4fmt.Println(id.String())

Python

main.go

1import uuid
2 
3id = uuid.uuid4()
4print(id)

PHP

main.go

1$id = Ramsey\Uuid\Uuid::uuid4()->toString();

Summary

UUIDs are a reliable way to create unique identifiers without needing a central authority. They are essential in modern systems, especially distributed systems where many components need to create IDs independently.

You should use UUIDs when:

multiple systems create data at the same time
you want globally unique IDs
you need secure, hard-to-guess identifiers
you work with microservices or offline-capable apps

Understanding how UUIDs work will help you build more scalable, safer, and more flexible applications.