Skip to content

Adding new named vectors to existing collections: server rejects PATCH, upserts silently drop data #1153

@ErcinDedeoglu

Description

@ErcinDedeoglu

Summary

There are two issues when working with named vectors on an existing collection:

  1. 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.

  2. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions