Why should you avoid over-partitioning a Milvus collection?

Partitions are lightweight compared to separate Collections, but they aren't free: each partition still carries some metadata overhead, and Milvus's practical guidance caps the reasonable number of partitions per collection well below what an unbounded "one partition per user" scheme might naively produce for an application with millions of users.

Beyond raw partition count limits, an excessive number of very small partitions can also reduce the effectiveness of Milvus's segment-based storage and indexing: segments are the actual unit indexes get built over, and having data fragmented across an enormous number of small partitions can lead to more numerous, smaller segments than an equivalent, less-fragmented data layout would produce, potentially working against efficient index utilization and increasing per-query coordination overhead across many partitions.

The practical guidance is to reserve partitions for genuinely meaningful groupings, like a moderate number of tenants, regions, or time buckets, rather than creating one partition per individual user or per individual small batch of data; for very fine-grained, high-cardinality grouping needs, a scalar field used as a search filter is usually the more appropriate and scalable tool than an equally fine-grained partition scheme.