Demystifying Sharding in MongoDB (MongoDB World 2022) 

I am not sure to understand your question, but I would say that having a high cardinality and even distribution of data are the most important criterion for the choice of shard key. Indeed you want your partitions to be as small as possible, so that the cluster can break your collection as much as possible if needed.

we also want our queries to hit as less shards as possible, am I right?

You can read and (most importantly) write in parallel from/to different shards at the same time. So to come back to your question, I'd say it depends on your use case: - For transactional apps, you want to be able to scale your write-throughput, by parallelising the WRITEs to different shards at the same time. - For analytical apps, you want to avoid having to read unnecessary data that would have to be filtered out, so yeah, you would want to store on the same partition data that is often read together. In practice, it means you'd partition your table according to a column that is often used as a filtering criteria or JOIN criteria. As you can see for the "Analytics" point, I'm using SQL-wording ('table", "JOIN"), because sharding in that context would be done by a RDBMS, such as AWS Redshift. But my understanding is that MongoDB is the 1st category of workloads: for transactional apps. In that case you want to partition your data so that there's no single partition handling most of the "write" operations; as you want to parralelize _writes_ so as to get the best write-throughput.