Pinecone workflow: raise read and write throughput deliberately

# Raising throughput without guessing

## Steps

1. **Batch.** Fewer, larger requests: upserts near the 2 MB cap, queries batched where the API allows. This alone often 2 to 5x effective throughput.
2. **Parallelize.** Concurrent requests with a bounded pool and exponential backoff on 429. Unbounded concurrency just moves the bottleneck to throttling.
3. **Separate read and write pressure.** Bulk ingests during off-peak; serving queries get priority. Do not benchmark reads during a backfill.
4. **Dedicated read nodes.** For sustained high read volume, indexes on dedicated read nodes are not subject to read-unit limits for query, fetch, list, and full-text search. This is the lever when batching and parallelism plateau.
5. **Consider pods.** Steady, predictable, very high throughput can be cheaper on dedicated pod capacity than serverless usage billing. Model both with your measured QPS.

## Traps

1. Raising concurrency to fix 429s: more concurrency into a throttle makes it worse. Back off, then batch.
2. Paying for dedicated capacity before measuring: the most expensive throughput is the kind you bought for traffic you do not have.
3. Optimizing writes when reads are the bottleneck (or vice versa): profile which side throttles before changing anything.