What Is a Unique Identifier and Why It Matters

1What Is a Unique Identifier?

A unique identifier is a value assigned to a record so that it can always be distinguished from every other record in the same system. It is the value other parts of the system rely on to look up, reference, or link back to that exact record.

Databases usually enforce this uniqueness through a primary key constraint, which rejects any attempt to insert a duplicate identifier value.

2Common Types of Identifiers

Most systems choose from a handful of well-established identifier strategies.

• Auto-incrementing integers: simple, compact, and easy to read, but they reveal record order and count, and require central coordination in a database.
• UUIDs (universally unique identifiers): 128-bit values that can be generated independently on separate machines with an effectively negligible chance of collision.
• Natural keys: an existing attribute of the data, like a national ID number or SKU, used directly as the identifier.
• Composite keys: a combination of two or more fields that together are unique, even though no single field is.

3Auto-Increment vs UUID

Auto-incrementing integers are compact and fast to index, making them a good default for single-database applications where central coordination is not a bottleneck.

UUIDs shine in distributed systems, offline-first applications, or anywhere multiple services need to generate identifiers independently without checking with each other first.

4Why Natural Keys Are Risky

Using a real-world attribute like an email address or phone number as a primary identifier seems convenient, but real-world data changes over time in ways identifiers should not.

An email address can be reassigned, a phone number can be recycled, and a username can be changed by the user, all of which break any system that assumed the value was permanent.

• Email addresses: users change providers or company employees leave.
• Phone numbers: carriers recycle unused numbers after a period of inactivity.
• Usernames: users frequently request changes for personal or branding reasons.

5Identifiers in APIs and URLs

Once an identifier is exposed in a public API or URL, changing its format later becomes a breaking change for every client and integration that depends on it.

This is why many teams generate an internal database identifier for performance and a separate, stable public identifier for anything exposed externally.

6Choosing the Right Identifier Strategy

For a small, single-database application, an auto-incrementing integer is usually the simplest and most performant choice.

For distributed systems, offline data collection, or anything where records might be created outside a central database, a UUID avoids coordination problems and collision risk.

7Common Mistakes

A few recurring mistakes cause real pain later in a system's life.

• Reusing identifiers after a record is deleted, which can silently link new data to old references.
• Choosing a natural key that later turns out to be mutable or non-unique in edge cases.
• Exposing internal sequential identifiers in public URLs, revealing business metrics unintentionally.

8Next Steps

When designing a new data model, decide on an identifier strategy early and document why it was chosen, since retrofitting a different identifier scheme onto an existing system is a significant migration effort.

Studying how established systems structure their primary keys and foreign keys is one of the fastest ways to build intuition for this kind of design decision.