Implement Qdrant multitenancy by partitioning one collection with a tenant payload field, is_tenant indexing, and optional custom shard-key routing

Documented steps

1. Follow the official recommendation: one collection per embedding model with payload-based tenant partitioning, not one collection per tenant.
2. Store the tenant id in each point's payload: PUT /collections/{collection_name}/points with {"points":[{"id":1,"payload":{"group_id":"user_1"},"vector":[0.9,0.1,0.1]}]}.
3. Filter every query by tenant: POST /collections/{collection_name}/points/query with {"query":[0.1,0.1,0.9],"filter":{"must":[{"key":"group_id","match":{"value":"user_1"}}]},"limit":10}.
4. Disable the global HNSW graph and rely on per-payload subgraphs: PUT /collections/{collection_name} with {"vectors":{"size":768,"distance":"Cosine"},"hnsw_config":{"m":0,"payload_m":16}}.
5. Create the tenant index with the tenant flag: PUT /collections/{collection_name}/index with {"field_name":"group_id","field_schema":{"type":"keyword","is_tenant":true}} (v1.11.0+). This co-locates each tenant's vectors on disk for sequential reads.
6. For uneven tenant sizes use tiered multitenancy (v1.16.0+): create the collection with {"shard_number":1,"sharding_method":"custom"}.
7. Create a shared fallback shard for small tenants: PUT /collections/{collection_name}/shards with {"shard_key":"default"}.
8. Route small tenants there on write: PUT /collections/{collection_name}/points with {"points":[...],"shard_key":{"fallback":"default","target":"user_1"}}.
9. Promote a large tenant to a dedicated shard: PUT /collections/{collection_name}/shards with {"shard_key":"user_1","initial_state":"Partial"}, then POST /collections/{collection_name}/cluster with {"replicate_points":{"filter":{"must":{"key":"group_id","match":{"value":"user_1"}}},"from_shard_key":"default","to_shard_key":"user_1"}}.
10. Reference: https://qdrant.tech/documentation/manage-data/multitenancy/