Random keys have the positive aspect of not creating any hotspots, and they have the negative aspect of not creating any hotspots. So if you have concurrent up

Random keys have the positive aspect of not creating any hotspots, and they have the negative aspect of not creating any hotspots. So if you have concurrent updates which are correlated with row insertion time, random keys can be a win. On the other hand, if your lookups are correlated with row insertion time, then the relevant key index pages are less likely to be hot in memory, and depending on how large the table is, you may have thrashing of index pages (this problem would be worse with MySQL, where rows are stored in the PK index). (UUID doesn't need to mean random any more though as pointed out below. My commentary is specific to random keys and is actually scar tissue from using MD5 as a lookup into multi-billion row tables.)