DEV Community

Cover image for Id or UUID: Which one should you use as the primary key in your DB?
danielAsaboro
danielAsaboro

Posted on

Id or UUID: Which one should you use as the primary key in your DB?

Carrying a successful attack on a highly-valued asset like the United States of America's President is pretty easy (and that's a big call) — but only if:

  • You know the exact place, time, and speed of the president's convoy
  • which of The Beast the President would be sitting in, and what he will be doing at that time.
  • the president's itinerary for the day, the security protocols in place, and his security team's usual habits etc

Okay, that's enough masterclass in terrorism 💀

What do all these shenanigans got to do with Web development and API Security, you ask? Well, it's pretty simple: A predictable system is inherently insecure.

This is why you are advised not to encrypt your user's password and instead asked to not just hash them, but also salt them.

So it wasn't a thing of surprise when I saw that using UUID instead of plain old sequential Ids was one of the things on Treblle API security Hackathon.

Excerpt From Trebble's blog

Just as a predictable system can be easily exploited in an attack on a public figure, a predictable system in the digital realm can be targeted by malicious actors — exposing sensitive information and jeopardizing the integrity of the entire system.

But there's a problem...

Implementing robust security measures to enhance the resilience of systems and reduces the risk of unauthorized access or exploitation doesn't come all rosy.

Let's take the use of UUID instead of plain sequential Id (ObjectId in MongoDb), for example. Yes, they have:

  • Universal Uniqueness.
  • Independence from central coordination.
  • Reduced risk of ID collision.
  • Flexibility and interoperability.
  • Future-proofing, scalability, and all the good stuff...

But at what cost?...

Is it their Sheer length?

Confused

They can be so long that they take up half of my database column or API payload. I'm just trying to store or transmit a simple identifier, but no, I have to deal with this monstrous string that seems to go on forever. It's not only inconvenient but also wastes valuable storage and network bandwidth.

Let's talk about Debugging

Debugging Pain

When an issue arises, and I need to dive into my database or logs to find the problematic record, I'm used to quickly identifying it based on its ID. But with UUIDs, I need to copy-paste that monstrosity and hope I don't make any mistakes. Good luck finding that needle in a haystack of cryptic strings.

On Performance

Generating a UUID takes significantly more computational resources compared to simply incrementing a sequential ID. So if I'm dealing with a high-throughput system or a massive number of records, the overhead of UUID generation starts to become a real bottleneck.

Oh, and don't even get me started on sorting or indexing UUIDs.

Slow Performance

With sequential IDs, it's a breeze.

I can simply order them by their values, and voila!

But with UUIDs, it's like trying to solve a complex puzzle. I have to resort to weird sorting algorithms, convert them to binary representations, or split them into multiple columns just to make them somewhat sortable.

It's a nightmare for anyone who values simplicity and efficiency.

UUID have their benefits, but the tradeoffs are real.

But don't get me wrong!

Although predictability is an open invitation for attacks and the element of surprise can transform into stronghold — Not all scenarios require or benefit from complete unpredictability.

Remember, when it comes to human-facing interfaces, intuitive and memorable IDs are crucial for a good user experience.

Users should be able to easily identify and remember entities or items based on their IDs. This is especially important in applications where users need to reference or communicate about specific items frequently.

And most applications like E-commerce Platforms, CMS (Content Management Systems), and Data Analytics platforms have specific sorting and indexing needs.

There's no one-size-fits-all solution.

One size fit all problem

Your choice should be driven your application requirements, specific needs, and the trade-offs you are willing to take on.

  • Evaluate them.
  • Consider the benefits.
  • And Weigh the Limitations.

That's the only way to make an informed decision. And this is the goal of this article.

⚠️⚠️ A big Note ⚠️⚠️

Throughout history, attacks on public figures, including heads of state, have unfortunately occurred. It is important to note that discussing these incidents should not be seen as endorsing or promoting violence.

Top comments (0)