Unexpected downsides of UUID keys in PostgreSQL

Re:Unexpected downsides of UUID keys in PostgreSQL by ljm on Thursday June 22, 2023 @11:34AM (#36433754)

I’ve worked with ULIDs a bit but honestly haven’t operated at a scale where you might run into issues. And the main reason for choosing ULID was because I could only find experimental support for UUIDv6 or UUIDv7, and KSUID (another alternative) only had time precision down to a second.

And the reason for that was to have lexicographically sortable IDs (even if not monotonic, which would require an extra server) so we didn’t have to index a timestamp column for chronological ordering. The alternative was to have a traditional integer sequence but it’s not always ideal to expose those on your API.

[ Parent | on HN ]

Re:Unexpected downsides of UUID keys in PostgreSQL by cratermoon on Thursday June 22, 2023 @12:26PM (#36434598)

Out of curiosity, why do your keys need time precision less than a second? Are they carrying some secondary expectations beyond uniqueness and k-sortable?

[ Parent | on HN ]

Re:Unexpected downsides of UUID keys in PostgreSQL by ljm on Wednesday June 28, 2023 @04:15PM (#36511960)

Uniqueness and the context is that we were modelling a chat conversation, so the limited precision presented issues with messages occasionally appearing out of order.

That also applied to our test suite so the choice was to use KSUID but still index a timestamp for accuracy, or just use an alternative with more precision.

[ Parent | on HN ]

Re:Unexpected downsides of UUID keys in PostgreSQL by esafak on Wednesday June 28, 2023 @04:56PM (#36512468)

What would you use for that application if you had to choose today?

[ Parent | on HN ]