What's a good practice for storing large binary blobs (e.g., raw images) associated with a point, given payloads are meant for structured metadata?

The standard practice is to store the blob in an object store (S3, GCS, Azure Blob) or a dedicated content store, and put a reference to it in the Qdrant payload. The reference is typically a URL, an object-storage key, or an opaque content ID. The payload then holds only the metadata needed for filtering, ranking, and retrieval, and the application resolves the reference when it needs the blob. This keeps the payload small, which keeps the payload index small, the memory footprint small, and the response size small. It also lets the blob be served from a CDN or a dedicated content service with its own caching, access control, and lifecycle management, which is a better fit for large binaries than a vector database. The pattern is the same as storing PII: keep the vector database for what it is good at (vectors and metadata) and put the large or sensitive content elsewhere.

The mechanism that makes this work is that Qdrant is optimized for small, structured payloads that can be indexed and filtered. Large binary content is not indexable, cannot be filtered on efficiently, and dominates the storage and memory cost. If you store an image in the payload, every payload read during a filtered query has to read the image bytes (or a pointer to them) and every response that returns the payload has to serialize and transmit the image. The result is slow queries, large responses, and a collection that uses far more memory than necessary. Storing a reference avoids all of this: the payload holds a short string, the index stays small, and the blob is fetched only when the application actually needs to display or process it. The trade-off is that the application now has two stores to manage and must handle the case where the reference points to a missing or inaccessible blob. In practice this is a small cost compared to the performance benefit.