I was hoping to see some more people chime in here, but I think the idea of the uuid is to replace the id column for a more unique id which is useful especially when you've got a distributed database or are dealing with replication.
Pros:
- Easier to merge data
- Better scaling when/if you have to move to a distributed system
- Avoids Postgres sequence problems which often occur when merging or copying data
- You can generate them from other platforms (other than just the database, if you need)
- If you're wanting to obfuscate your records (e.g. rather than accessing
users/1
(the id) which might prompt a curious user to tryusers/2
to see if he could access someone else's information since its obvious the sequential nature of the parameter). Obviously there are other ways of dealing with this particular issue however
Cons:
- Requires larger key length that typical id
- Is usually non-sequential (which can lead to strange behavior if you're ordering on it, which you probably shouldn't be doing generally anyhow)
- Harder to reference when troubleshooting (finding by a long UUID rather than an simple integer id)
Here are some more resources which I found valuable:
- Peter van Hardenberg's (of Heroku) argument for UUIDs (among other things, this is an amazing presentation and you should watch all of it)... Here's the part on using UUID's rather than ids: http://vimeo.com/61044807#t=15m04s
- Jeff Atwood's (formerly of StackOverflow) argument for GUIDs: http://www.codinghorror.com/blog/2007/03/primary-keys-ids-versus-guids.html
- http://rny.io/rails/postgresql/2013/07/27/use-uuids-in-rails-4-with-postgresql.html
- http://blog.crowdint.com/2013/10/09/using-postgres-uuids-as-primary-keys-on-rails.html