Database UUID Keys: Pros & Cons, and smarter alternatives

Introduction

While designing databases, one of the important decisions is how to uniquely identify each row in a table. Universally Unique Identifiers (UUIDs) are a popular choice to ensure uniqueness across different systems. However, this approach comes with performance and storage challenges, especially as the database expands.

In this article, I will discuss what UUIDs are, the performance issues they can cause, explore better alternatives, and situations where using UUIDs are better choice.

What Are UUIDs?

A UUID (Universally Unique Identifier) is a 128-bit number used to uniquely identify objects or records in computer systems. There are different versions of UUIDs, but the most commonly used is UUIDv4, which is randomly generated. Here’s an example:

z945bce7-afdc-4y57-b349-5fghh88832b1

The digit ‘4’ in the 13th position indicates that this is a UUIDv4.

UUIDs are useful when unique identifiers need to be created across multiple systems without coordination. This makes them ideal for distributed applications. However, using UUIDs as primary keys in a database can lead to performance issues.

Performance Issues with UUIDs

1. Slower Insert Performance

Most databases use B+ Trees for indexing, which helps speed up searches. When inserting records with an auto-incrementing integer key, the database can easily place them in order. However, UUIDs are randomly generated, so new records are inserted in scattered positions, requiring frequent rebalancing of the B+ Tree.

As the database grows to millions of records, this frequent rebalancing slows down insert operations significantly.

2. Higher Storage Requirements

UUIDs take up more space compared to traditional auto-incrementing integer keys. Here’s a comparison:

• Auto-incrementing integers: 32 bits per value

• UUIDs: 128 bits per value

That’s four times the storage per row! If stored as a human-readable string, UUIDs can take up to 688 bits, which is 20 times more than an integer key.

For large tables with millions of records, UUIDs can significantly increase database storage size and costs.

Performance Comparison: UUIDs vs. Auto-Incrementing Integers

Let’s compare two tables, one using UUIDs and the other using auto-incrementing integers, each with 1 million rows:

• Total table size: The UUID table is about 2.3 times larger than the integer table.

• ID field size: A UUID field requires 9.3 times more storage than an integer field.

• ID column size: The UUID column is 3.5 times larger than the integer column.

These differences impact query speed and database efficiency.

Alternatives to UUIDs

While UUIDs are widely used, there are better alternatives for many situations. Here are some:

1. UUIDv7

• What it is: A time-based UUID version where identifiers are generated in increasing order.

• Why it’s better: Because UUIDv7 is sequential, it improves indexing performance while maintaining global uniqueness.

• Best for: Applications needing globally unique IDs but with better database performance than UUIDv4.

2. Auto-Incrementing Integers

• What it is: A sequential number automatically generated for each new row.

• Why it’s better: Since records are inserted in order, it optimizes indexing and storage, making queries faster.

• Best for: Small to medium-sized databases or single-system applications where global uniqueness isn’t required.

3. ULID (Universally Unique Lexicographically Sortable Identifier)

• What it is: A globally unique ID that is also sorted in order.

• Why it’s better: It uses a timestamp-based prefix followed by randomness, ensuring efficient inserts while maintaining uniqueness.

• Best for: Distributed systems where ordering is important for performance.

When Should You Use UUIDs?

Despite their downsides, UUIDs are the best choice in certain cases:

1. Distributed Systems: When multiple systems generate IDs independently, UUIDs ensure uniqueness without conflicts.

2. Merging Data from Different Sources: If you’re combining records from multiple databases, UUIDs prevent duplicate IDs.

3. Public Exposure: UUIDs are harder to guess than sequential numbers, making them more secure for URLs and APIs.

However, for single-system applications or cases where global uniqueness isn’t a priority, using auto-incrementing integers or UUID alternatives like UUIDv7 or ULID is often a better choice.

Conclusion

UUIDs provide global uniqueness, making them essential for distributed systems. However, they also introduce performance and storage challenges, particularly when using UUIDv4 due to its random nature. If you need a balance between uniqueness and performance, consider alternatives like UUIDv7 or ULID. For simpler applications, auto-incrementing integers remain a reliable choice.

Ultimately, choosing between UUIDs and other options depends on your system’s requirements. If uniqueness across systems is crucial, UUIDs (especially UUIDv7) are a great choice. But if performance and storage efficiency are more important, other options may be a better fit.