Whether to use Globally Unique Identities (Guid)'s or not use Guids for primary keys comes up regularly.

In order to make an informed decision, here are some important notes.

  • Guids are defined by RFC 4122.
  • When dealing with different machines, it's important to use the same mechanism, to reduce the risk of clashes.
Types of Guids

There are various types of Guids:

Time based (Variant 2, Version 1 RFC 4122) GUIDs: * P/Invoke UuidCreateSequential

  • uuidgen.exe, passing the -x flag

Random (Variant 2, Version 4 RFC 4122) GUIDs: * Guid.NewGuid() is a Variant 2, Version 4 RFC 4122 GUID (random based).

  • Note that internally it P/Invokes CoCreateGuid which in turn invokes UuidCreate

* guidgen.exe (in Visual Studio/Windows SDK) is a Variant 2, Version 4 RFC 4122 GUID (random based). * uuidgen.exe tool (in SDK) is a Variant 2, Version 4 RFC 4122 GUID (random based). * P/Invoke UuidCreate

  • note: that prior to NT UuidCreate was Version 1 (time-based), but you'll never have to worry about it.

Non-RFC 4122 compliant:

  • SqlServer's newsequentialid() is reshuffled Random one. And unfortunately reshuffles the position of the Variant bit. Bummer.
    • No shit…MS created a non-client solution on something so damn important to stick to an RFC

When using GUIDs as keys in a database, you must ensure that the GUIDs are all compatible with each other.

Not compatible:

  • newsequentialid() is not compatible with Guid.NewGuid
  • newsequentialid() is not compatible with UuidCreateSequential (unless you're doing byte swapping manually).


  • Guid.NewGuid and UuidCreateSequential are compatible with each other (since they are both RFC 4122 compliant).
  • Other made-up GUIDs - including “comb” GUIDs (webcite) - are not compatible with any other type of GUID.
Regarding SQL Server

Sql Server: * doesn't do as expected, and orders GUID values according to the least significant six bytes (i.e. the last six bytes of the Data4 block).