What is a realistic batch size for bulk-loading millions of Qdrant points, and what factors should influence it?

There is no universal Qdrant batch size that is correct for every workload. I would start with a moderate batch, often on the order of hundreds to a few thousand points, and benchmark from there rather than treating a fixed number as a rule.

The main variables are the serialized payload size, vector dimensionality, network bandwidth, client memory, Qdrant CPU and RAM, index maintenance cost, write concurrency, and acceptable retry latency. A batch containing 2,000 small vectors may be easy to handle while 2,000 large multivectors can be enormous.

I would increase the batch until throughput stops improving or tail latency, memory pressure, request failures, or Qdrant resource contention becomes unacceptable. I would also tune concurrency separately because ten medium batches in flight can behave very differently from one huge batch.

A common mistake is optimizing only requests per second. For a production ingestion pipeline I care about points per second, bytes per second, Qdrant resource utilization, failure rate, and the impact on interactive search. The optimal value is workload- and deployment-dependent.