News for hackers. Stuff that matters.

A comment on Unexpected downsides of UUID keys in PostgreSQL. Parent comment

Re:Unexpected downsides of UUID keys in PostgreSQL by ceeam on Thursday June 22, 2023 @08:29AM (#36431121)
Their uniqueness of course.

> To be able to generate keys independently of the database

> To move sets of related records between different databases without having to deal with renumbering everything

[ Parent | on HN ]
Re:Unexpected downsides of UUID keys in PostgreSQL by yes_man on Thursday June 22, 2023 @08:36AM (#36431202)
And adding greppability of logs in debugging situations. You can just search logs in any systems of yours with the UUID and find exact hits you are dealing with. Whereas with integers you will get all kinds of hits
[ Parent | on HN ]
Re:Unexpected downsides of UUID keys in PostgreSQL by phkahler on Thursday June 22, 2023 @09:37AM (#36431975)
Because UUIDs are universally Unique IDentifiers.
[ Parent | on HN ]
Re:Unexpected downsides of UUID keys in PostgreSQL by jandrewrogers on Thursday June 22, 2023 @06:07PM (#36439789)
Unfortunately, UUIDs aren't as universally unique in practice as people think. The standard flavors are banned in quite a few organizations that care a lot about data integrity for valid reasons. Standard UUIDs work for some applications but definitely not all.

For most applications you are better off using a sensible structured key, like incrementing an integer or similar, and encrypting it if you want to obscure it. Encrypting a 128-bit value is approximately free on modern CPUs.

[ Parent | on HN ]