Do you really need a UUID/GUID?

With UUIDs for keys, you can shard your database, then later merge or migrate parts with no issues about collision or reindexing. That's useful. Whole coding tasks (and whole classes of bugs) disappear entirely.

> Sequential values tend to index well because they don't require large sections of the index to be realigned

Erm... What? I don't understand this sentence at all, and I know well how indexing works.

> [MySQL performance] Notice the nearly consistent insertion time of a long integer vs. the UUID.

Oh boy. You just found out that (a) MySQL is a subpar product and (b) that inserting 4 or 8 bytes is faster than inserting 36 bytes.

How about inserting 8 bytes (int64) vs. inserting 16 bytes (deicated UUID type) in PostgreSQL?

> Auto incremented integers will almost always be smaller, meaning scans against tables/records will be more efficient.

And this is because...?

You know how B-trees work, do you? And you do know that you very rarely need a sequential iteration over artificial key in a database?