Summary
There are two issues when working with named vectors on an existing collection:
-
Cannot add a new named vector to an existing collection — the server rejects PATCH /collections/{name} with a 400 when the vector name doesn't already exist. The Python SDK's VectorsConfigDiff type correctly reflects this server limitation, but neither server nor SDK offer any way to add a new named vector without recreating the collection.
-
Upserting points with a non-existent vector name returns HTTP 200 but silently drops the data — this is dangerous because the client receives a success response while the server quietly declines the operation with only a WARN-level log.
Environment
- qdrant-client: 1.16.2
- Qdrant server: 1.16.3 (
qdrant/qdrant:v1.16.3)
- Python: 3.11
Issue 1: Cannot add named vectors to existing collection
Reproduction
import httpx
client = httpx.Client(...)
# Create collection with one named vector
client.put("/collections/test", json={
"vectors": {"model_a": {"size": 768, "distance": "Cosine"}}
})
# Try to add a second named vector via PATCH — 400 error
r = client.patch("/collections/test", json={
"vectors": {"model_b": {"size": 1024, "distance": "Cosine"}}
})
# → 400: "Wrong input: Not existing vector name error: model_b"
Server log
INFO storage::content_manager::toc::collection_meta_ops: Updating collection test
INFO actix_web::middleware::logger: "PATCH /collections/test HTTP/1.1" 400 88
Use case
We run a single shared collection with multiple named vectors for different embedding models (e.g., azure_text_embedding_3_large_3072 for one agent and nim_llama_3_2_nv_embedqa_1_0_2560 for another). When a new embedding model is introduced, we need to add its named vector to the existing collection without dropping and recreating all existing data.
Currently the only option is to recreate the collection with all vectors pre-defined, which requires re-ingesting all data.
Request
Support adding new named vectors to an existing collection via PATCH /collections/{name}, or provide a dedicated endpoint for this. This would enable multi-model collections to evolve without data loss.
Issue 2: Upserts with non-existent vector name return 200 but silently drop data
This is arguably the more critical issue.
Reproduction
# Collection only has "model_a" defined
client.put("/collections/test/points", json={
"points": [{
"id": 1,
"vector": {"model_b": [0.1] * 1024}, # model_b does NOT exist
"payload": {"test": "data"}
}]
})
# → HTTP 200 {"result": {"operation_id": 2, "status": "acknowledged"}}
#
# Client thinks success. Data is gone.
Server log
WARN collection::collection_manager::collection_updater: Update operation declined:
Wrong input: Not existing vector name error: model_b
INFO actix_web::middleware::logger: "PUT /collections/test/points HTTP/1.1" 200 73
The server logs a WARN and declines the operation, but returns HTTP 200 to the client. The client has no way to detect the failure without parsing server logs.
Expected behavior
The upsert should return an error status (400 or 422) when a point references a vector name that doesn't exist in the collection config. Returning 200 for a silently declined write is a data loss vector — applications believe they've persisted data that was actually dropped.
Additional PATCH observations
Other PATCH body formats also return 200 but are no-ops:
| Format |
HTTP Status |
Actual Result |
{"vectors": {"new": {size, distance}}} |
400 |
Correctly rejects |
{"params": {"vectors": {"new": {size, distance}}}} |
200 |
Silent no-op |
{"vectors_config": {"new": {size, distance}}} |
200 |
Silent no-op (unknown field ignored) |
Versions tested
All behavior confirmed on Qdrant server v1.16.3 with qdrant-client v1.16.2.
Summary
There are two issues when working with named vectors on an existing collection:
Cannot add a new named vector to an existing collection — the server rejects
PATCH /collections/{name}with a 400 when the vector name doesn't already exist. The Python SDK'sVectorsConfigDifftype correctly reflects this server limitation, but neither server nor SDK offer any way to add a new named vector without recreating the collection.Upserting points with a non-existent vector name returns HTTP 200 but silently drops the data — this is dangerous because the client receives a success response while the server quietly declines the operation with only a WARN-level log.
Environment
qdrant/qdrant:v1.16.3)Issue 1: Cannot add named vectors to existing collection
Reproduction
Server log
Use case
We run a single shared collection with multiple named vectors for different embedding models (e.g.,
azure_text_embedding_3_large_3072for one agent andnim_llama_3_2_nv_embedqa_1_0_2560for another). When a new embedding model is introduced, we need to add its named vector to the existing collection without dropping and recreating all existing data.Currently the only option is to recreate the collection with all vectors pre-defined, which requires re-ingesting all data.
Request
Support adding new named vectors to an existing collection via
PATCH /collections/{name}, or provide a dedicated endpoint for this. This would enable multi-model collections to evolve without data loss.Issue 2: Upserts with non-existent vector name return 200 but silently drop data
This is arguably the more critical issue.
Reproduction
Server log
The server logs a WARN and declines the operation, but returns HTTP 200 to the client. The client has no way to detect the failure without parsing server logs.
Expected behavior
The upsert should return an error status (400 or 422) when a point references a vector name that doesn't exist in the collection config. Returning 200 for a silently declined write is a data loss vector — applications believe they've persisted data that was actually dropped.
Additional PATCH observations
Other PATCH body formats also return 200 but are no-ops:
{"vectors": {"new": {size, distance}}}{"params": {"vectors": {"new": {size, distance}}}}{"vectors_config": {"new": {size, distance}}}Versions tested
All behavior confirmed on Qdrant server v1.16.3 with qdrant-client v1.16.2.