Hi, I have been thinking for some time about using UUIDs as primary keys in databases. Right now I turned away from it and use a normal integer as primary key + add a second column UUID which I expose to the client. The problem is that I will always have to get a reference to the object in the database by UUID until I can do some joins on the ID. I wonder what the performance implications are referencing or searching for UUIDs in a database (indexed or not). Are there any papers on that? Posts? Some other docs?

uuids tend to have a randomish distribution, which can be problematic for preformance (can bypass caches at different levels)

I would consider some kind 'flake' implementation so your ids are k-ordered, if you haven't yet, I know I've seen blog posts comparing the performance of UUID and bigint keys in postgres, so maybe google for those

flakes: http://yellerapp.com/posts/2015-02-09-flake-ids.html

@hiredman: Thanks, I have not heard of flake ids yet, will read up on them.