I agree UUIDs are great. This article barely scratches the surface. Other reasons to use UUIDs (aside from added security) include:

- Database systems which use UUIDs scale better because if you have multiple shards of the same table on different machines, it's impossible to reliably know which numeric ID was the last one since you may have concurrent writes on both tables at the same time.

- UUIDs make it possible to recover from insertion failures without relying on atomic database transactions. For example; if you have a single function which inserts data into multiple related tables and it fails part-way through; how can the function’s caller know which insertion operations succeeded and how can you recover from this? With auto-incrementing integer IDs, you can't just retry the entire operation (call the function again) because you risk inserting duplicate records. With UUIDS, however, you can simply retry all the exact same operations; if any record was already inserted, you will get a conflict which will prevent duplicate records from being inserted. if any table insertion gets an error, you can simply check the error code and if it's a primary key conflict, you can just log a message and continue with other table insertions (you treat conflicts as a success since it means that the record was already inserted).

I recommend to use UUIDs as primary keys but, as mentioned in this article, some databases don't handle them very efficiently. MySQL doesn't handle them very efficiently, however, Postgres does.