I’ve done it both ways. In general I feel like “avoid GUID as PK” is a premature optimization. It takes a ton of records… more than most systems will see (SQL Server has gotten much better about GUID PKs over the years)… for the performance difference to be noticeable. Meanwhile, creating a separate INT PK and GUID public ID… well, now I need the developers to remember to use that GUID public ID, and my experience has been that every door the architect leaves open for the developers to make a mistake is a door a developer will walk through, and now I am counting on code reviews and such to detect that mistake. Code reviews are well and good, but they are hardly foolproof, and it’s very easy for the eyes to glaze over and miss a detail like an exposed internal INT PK.

So my *current* thinking, always subject to change, is that it’s better to use GUID PKs until the performance suffers, unless I know in advance it will be a monster sized table and then I can just start with INT PK and a GUID public ID.

J.Ja