UUID vs GUID vs CUID vs NanoID: A guide to database primary keys

When you're working on database design, how you uniquely identify each record matters—a lot. The ID type you choose can have implications on performance, scalability, and ease of use. Here's a look at some popular options for auto-generated IDs.

UUID and GUID: The Big Names

UUID and GUID are like the Coke and Pepsi of the ID world—different brands, same taste. They're both 128-bit, RFC 4122 compliant IDs that pretty much guarantee uniqueness across time and space. GUID is essentially Microsoft's flavor of UUID.

Pros: Universally recognized, super high chance of being unique.

Cons: They're long—36 characters, including dashes. Also, because they're random, some databases can get a bit stressed out trying to index them, which can lead to performance issues.

CUID: The Scalable Option

CUID is shorter and timestamp-based. It's designed to work well in multi-process systems, where you have a lot of IDs being generated in parallel.

Pros: Shorter than UUIDs/GUIDs, includes a timestamp, and still offers good collision resistance.

Cons: Not as universally recognized, and still a bit longer than you might want for simple tasks.

NanoID: The Compact Contender

NanoID is small and URL-friendly, but still packs a punch when it comes to collision resistance.

Pros: Short, sweet, and URL-friendly.

Cons: It's not as widely used yet, so you're banking on a less established standard. No timestamp if you're into that sort of thing.

Auto-Incrementing Integers: The Classic

And then there are auto-incrementing integers. You start at 1, and go up for every record created. Simple.

Pros: Super fast to generate and query, takes up minimal space, and it's simple to understand.

Cons: Not globally unique, which can be a problem if you ever need to merge databases. Also, exposes the size of your database, which could be a security risk.

The Bottom Line

• Use UUID/GUID if you want the granddaddy of universal IDs and you're willing to deal with the length.
• CUID is a good middle-of-the-road option for distributed systems and when you want some time-based sorting.
• Go NanoID if you want to keep it short and sweet, and you don't need a timestamp.
• Auto-incrementing integers are best for small-scale apps where performance is crucial and you don't anticipate merging databases.

Each option has its place; just pick based on what your specific project needs.

If you're using Prisma with your database, check out our other post on how to generate UUIDs in Prisma.