Why Choose ULIDs Over Traditional UUIDs or IDs for Database Identification?

Why Choose ULIDs Over Traditional UUIDs or IDs for Database Identification?

Exploring ULIDs: A Superior Alternative for Enhanced Database Security and Efficiency

May 5, 2024ยท

3 min read

Database security is really important when it comes to building custom web applications. One of the most common mistakes people make when creating their database is using regular IDs.

Not only are they in chronological order and visible with just an inspect on the network of dev tools, but also finding vulnerabilities and reverse-engineering your web app can be 10 times easier.

Today, we are going to see one alternative to both UUID and regular IDs. I've implemented this on all of my custom website apps in the past year.

What is ULID

To begin with, you can read the ulid spec here and see for yourself, but let's cover some important facts. ULID stands for Universally Unique Lexicographically Sortable Identifier. As its name implies, it is unique and sortable, and it looks like this 01ARZ3NDEKTSV4RRFFQ69G5FAV.

It has implementations for almost every language and can replace the other two in almost every scenario. In other words, wherever you need indexing and sharding, you can use ULID.


It is 128-bit compatible with UUIDs, which means they are the same size but shorter in length. So, you can easily replace UUIDs in databases or object storage systems.

It can also be used on Kafka and RabbitMQ.

Also, you can generate 1.21e+24 unique ULIDs per millisecond. This is not really important whether it is lower or higher than UUIDs because it is already a very large number.

Don't forget that it is more URL-friendly than UUIDs.Comparisons

FeatureID (id)UUID (uuid)ULID (ulid)
FormatInteger128-bit hexadecimal string128-bit string
GenerationSequentialRandom or time-basedTime-based and random
ReadabilitySimple and shortLong and complexShorter, human-readable
UniquenessNot guaranteed across shardsGlobally uniqueGlobally unique
Generation speedFastestSlower than idSlower than id
Use across distributed systemsPoorExcellentExcellent
Time-basedNoOptional (UUID v1)Yes
Collision riskLow in single instanceExtremely lowExtremely low
Storage efficiencyHighLowerLower
Implementation complexityNoneMore complexSlightly more complex


It can be very simple to implement. I am going to show one example in Kotlin with Spring Boot to demonstrate how simple it is. Just find a library that generates ULIDs and update your models.

import com.github.f4b6a3.ulid.UlidCreator

@Table(name = "users")
data class UserModel(
    var id: String = UlidCreator.getUlid().toString(),

    // other fields

) : UserDetails {
    // yourcode

Is it worth it ?

I am not going to cover all the reasons why Ulid is better, but in the end, it's up to your personal preference. I believe in the long run it gives you an advantage. Even if you create a small API, switching early on to Ulid is a benefit. Having to change mid-way through production can be challenging.


In conclusion, ULIDs offer a compelling alternative to traditional UUIDs and simple numeric IDs, particularly for applications requiring both uniqueness and sortability.

Their compatibility with UUID standards, coupled with features like time-based generation and global uniqueness, make ULIDs particularly suitable for distributed systems where sorting and scalability are crucial. While the implementation may be slightly more complex than basic IDs, the long-term benefits in terms of system performance and maintainability can justify the initial effort.

Thanks for reading, and I hope you found this article helpful. If you have any questions, feel free to email me at, and I will respond.

You can also keep up with my latest updates by checking out my X here: