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.

javascript

1
Start with a measured moderate batch rather than a universal number
2
Vector dimensions and payload size strongly affect request size
3
Tune batch size together with write concurrency
4
Measure throughput, tail latency, resource utilization, and failure behavior

Difficulty: 5/10

Topics: Batch size, Bulk ingestion, Performance

Scenario Questions

0-2 years experience

1
Your importer currently sends one point per request. What simple change would you test first to improve throughput?
2
Why might 1,000 small vectors be easier to send than 1,000 large multivectors?

2-5 years experience

1
Increasing batch size from 500 to 5,000 improves throughput but causes request timeouts. How would you choose a better operating point?
2
Your network can handle large requests but Qdrant memory usage spikes during ingestion. Which tuning dimension would you investigate?

5-8 years experience

1
Bulk loading competes with interactive search and causes p99 query latency spikes. How would you tune batch size and concurrency together?
2
A batch-size benchmark is excellent on staging but poor in production. Which workload characteristics could explain the difference?

8+ years experience

1
You need to ingest a billion points while preserving a strict search SLO. How would you design a benchmark matrix across batch size, concurrency, index state, and resource limits?
2
Your workload contains multiple vector sizes and payload distributions. Would you use one fixed batch size or adaptive batching? Design the approach.

Follow-up Questions

❓What metrics would you monitor while tuning batch size?
❓How is batch size different from ingestion concurrency?