title: Implications of using /id for the partition key in CosmosDb
body: <p>In the scenario where we have 1000 entries (unique keys) entering cosmos per minute, is it safe to use /id as the partition key? </p>
  
  <p>In particular, there is the concept of Logical Partitions 
  <a href="https://docs.microsoft.com/en-us/azure/cosmos-db/partition-data" rel="noreferrer">https://docs.microsoft.com/en-us/azure/cosmos-db/partition-data</a>
  The graphic here scares me a little bit, showing that the logical partitions are actual entities (Ex. "city": "London"). If I have an 8 hour TTL and 1000 entries per minute, I don't necessarily want 480,000 logical partitions that cosmos needs to manage. </p>
  
  <p>What I imagine happens is that the value of the partition key is simply hashed and modulo with the number of physical partitions, ex.
  <a href="https://docs.microsoft.com/en-us/azure/cosmos-db/partitioning-overview#choose-partitionkey" rel="noreferrer">https://docs.microsoft.com/en-us/azure/cosmos-db/partitioning-overview#choose-partitionkey</a>
  indicates that this is true in the "Logical Partition Mangement" section. Furthermore, the "Choosing a Partition Key" section suggests (but does not actually state) that /id would be a fantastic partition key, as it doesn't have to worry about the 10GB limit, throughput limit, no hot spots, wide (huge) range of values, and since the application doesnt need to filter on anything except the id, cross partition queries wont be an issue for this use case. </p>
  
  <p>In summary, do I need to worry about the memory/CPU/etc overhead of hundreds of thousands of partition key values (logical partitions)? The docs indicate the more values of the partition key is better, but don't say if its possible to have too many values. </p>