Clustered Sequential GUID Primary Key vs Non-Clustered GUID and Clustered Sequential ID Primary Keys I'm trying to figure out what the optimal solution is in regards to size and performance when using GUIDs as a primary key. The main reason for wanting GUIDs is that it's more appropriate in our micro-service architecture. There seems to be a lot of debate on what's actually best.

The two main solutions appear to be:


Have the primary key as a sequential GUID (generated by the
application, rather than SQL Servers built in NEWSEQUENTIALID() as it isn't truly sequential)
with a clustered index.
Have two primary keys, a randomly generated GUID with a
 non-clustered index and a basic int IDENTITY column with a
 clustered index -- the approach is described best in this stackoverflow response here


I'm not sure which solution is best. The first method seems to be the most popular and widely used from what I've read. The second seems to have this benefit from that linked stackoverflow response:


  Then there's another issue to consider: the clustering key on a table will be added to each and every entry on each and every non-clustered index on your table as well - thus you really want to make sure it's as small as possible.


Any advice would be appreciated.
If you're going to use a GUID key, simply use a clustered index with NEWSEQENTIALID() and move on with your application.  The alternative designs are simply not predictably and significantly better when you consider the extra data structures and complexity they introduce.  So while careful testing of your actual application might reveal a superior alternative design, just start with a simple clustered index on a sequentially-generated GUID.
For the gory details on why it doesn't really matter that the GUIDs are generated in the &quot;middle&quot; of the sort order, and the insertion point changes see: Good Page Splits and Sequential GUID Key Generation.