I recently started working on an application that has merge replication for offline scenarios. We have an int identity column that serves as the pk and clustering index. We also have uniqueidentifier column in each table because replication needs it. In the field, because of identity column, we sometimes face issue that the identity range runs out for 1 or more subscription databases. Then our support gets involved and spends lot of time compacting that tables, re-initializing subscription etc. To get rid of this problem, I see 2 solutions. 1. Use BigInt column instead of int and keep identity. This will give bigger ranges and hopefully we’ll never see that issue again. 2. Get rid of identity column and make the uniqueidentifier column serve as pk and clustering index. This column is already populated with newseqeuntialID(). This will permanently get rid of the problem. This will also reduce the overall size of the table since 1 column is gone from the table but it will increase size of the foreign key indexes and other non-clustered indexes.
I did some load testing and although bigint came little ahead in terms of timings, there wasn’t a huge difference.
What do you think about these 2 options or any other option that I didn’t think of?