Be Careful with UUID or GUID as Primary Keys
One of the post's points is that UUIDs will scatter your writes across the database, and that for this reason you want a (more or less) sequential key as your primary key. This crucially depends on both your database technology and your query patterns.<p>In a single-node database or even a manually-sharded one, this post's advice is good (For Friendfeed, we used a variation of the "Integers Internal, UUIDs External" strategy on sharded mysql: <a href="https://backchannel.org/blog/friendfeed-schemaless-mysql" rel="nofollow">https://backchannel.org/blog/friendfeed-schemaless-mysql</a>).<p>But in a distributed database like CockroachDB (Disclosure: I'm the co-founder and CTO of Cockroach Labs) or Google Cloud Spanner, it's usually better to get the random scattering of a UUID primary key, because that spreads the workload across all the nodes in the cluster. Sometimes query patterns benefit enough from an ordered PK to overcome this advantage, but usually it's better to use randomly-distributed PKs by default.<p>For CockroachDB, my general recommendation for schema design would be to use UUIDs as the primary keys of tables that make up the top level of an interleaved table hierarchy, and SERIAL keys for tables that are interleaved into another. (Google's recommendations for Spanner are similar: <a href="https://cloud.google.com/spanner/docs/schema-design#choosing_a_primary_key" rel="nofollow">https://cloud.google.com/spanner/docs/schema-design#choosing...</a>)