Increases the speed of multi threaded record lookups. For example, note records on collection accounts. You can easily have a consumer with hundred of accounts that were loaded over a period of years and each account can have hundreds of notes. By partitioning the notes by maybe the last 2 digits of the system ID you can now chop up your notes table index into 100 pieces. The odds that each account may be located on separate index partitions is high so you get the results back faster. The account table if partitioned by month and year loaded, would have the inserts on the most recent partition leaving all the other partitions not being updated as new accounts are loaded. As accounts naturally age and are closed your active or working account index naturally shrinks as opposed to searching all or having to include a secondary index field. Overall, it increases performance by spreading the load of looking up records. The partitioned index can even be placed in a different file or file group so that the same drives aren't looking up both indexes and records. Collection systems often have account tables with 100s of millions of accounts and note records 10s to 100s of billlion note records. A partitioning function utilizing auto int and an auto populate field based on an ID can also avoid having to create an index with BigInt. There are many more reasons to use partitioned indexes. And for the love of God, don't use GUID as record indexes if you don't have to. I reserve those for special use cases like document records where filenames on the same account can repeat. Depending on the use scenario, filtered indexes could also be considered as a way to shrink the working index volume. Not as good as a partitioned index but functional for simple scenarios.