Thanks for commenting! I think DB support is great. I'm especially jealous of postgres, which like you mention, has native UUID types. UUID-OSSP is especially g

Thanks for commenting! I think DB support is great. I'm especially jealous of postgres, which like you mention, has native UUID types. UUID-OSSP is especially great: http://www.postgresql.org/docs/devel/static/uuid-ossp.html http://www.postgresql.org/docs/devel/static/uuid-ossp.html Postgres handles all the gunk for you in terms of efficient storage and display, AND you can cluster by a different field than the UUID one. For those of us not unfortunate enough to be using a DB that has such niceties, things are different :) As for performance I think this will always depend on your what your queries look like. For random reads or for reads when your dataset is not larger than RAM, you won't see any degradation because of caching. But if you need to make tons of range queries on a dataset that doesn't fit in RAM (or even worse, the index doesn't fit in RAM), things can get a bit crazy. I wish I had time to also do a benchmark supporting this, but I've hit this issue before. Other people also seem to have hit it here: http://stackoverflow.com/questions/2365132/uuid-performance-in-mysql http://stackoverflow.com/questions/2365132/uuid-performance-... (comments and answers) or here: https://news.ycombinator.com/item?id=5310662 https://news.ycombinator.com/item?id=5310662 or here: http://www.mysqlperformanceblog.com/2007/03/13/to-uuid-or-not-to-uuid/ http://www.mysqlperformanceblog.com/2007/03/13/to-uuid-or-no... So, it really depends on your use case, I guess. Hope this helps!