Using a UUID (Universally Unique Identifier) as a primary key in SQL databases has both advantages... Tagged with sql.

Dev.to is a community platform for developers, offering resources, discussions, and networking opportunities to empower individuals in their coding journey. Developers can learn new programming languages, frameworks, and tools, engage in discussions on best practices, and share their experiences with fellow developers to enhance their skills and grow their professional network.

Using a UUID as a primary key in SQL databases has advantages and disadvantages. UUIDs have larger storage requirements and decreased performance compared to integers. They are not human-readable, making debugging and manual inspection challenging. UUIDs may result in suboptimal disk I/O patterns and higher levels of index fragmentation. Storing UUIDs increases storage requirements. Managing UUIDs adds complexity to application logic.

Why you should never use an UUID as the primary key in SQL Databases

No… A lot of fluff and no real solution. The highest up-voted comment says it all:
<blockquote>
And how would you ensure pk uniqueness on a same entity in a distributed system?
</blockquote>
<blockquote>
Because you can’t do it with int autoincrement.
</blockquote>
He goes on and is 100% correct:
<blockquote>
UUID exists for a reason and people use it for a reason.
</blockquote>

“should never” is misleading.

Thank you, a lot.
This was awesome.
It would be a plus if you take about UUID alternative like <a href="https://github.com/ulid/spec" target="_blank" rel="noopener nofollow">ULID</a>.

I not even think UUID as UID anymore, I prefer ULID since it breaks the disadvantages of UUID.

One may or may not agree. But what we need ultimately here is proof, not only statements. Even if I agree with the statement, I prefer scientific aproach than opinion.