# Behind the Benchmarking Pipeline
Dean Smith · 2026-07-16
**TLDR:** Sizing a Pinecone deployment (on-demand or dedicated, how many replicas, which node type) used to mean an engineer hand-running load scripts on an EC2 box and eyeballing the output, one question at a time. A pipeline now takes a workload spec, builds and loads a matching index, and sweeps it across the full grid of configurations automatically, so customers get a sizing recommendation backed by a measurement of their own workload instead of an engineer's best guess.
---
Every meaningful architecture decision a customer makes on Pinecone comes down to a question that can't be answered by looking at a schema alone. **How will this actually behave under my workload?**
For a long time, the only way to answer that was an engineer hand-running load scripts on an EC2 box and eyeballing the output. That worked for one question at a time, not the volume of sizing decisions Pinecone actually needed to make, and it left customers without a number they could plan against.
To close that gap, Pinecone built a pipeline that takes a workload spec and turns it into a fully provisioned, loaded, and measured index automatically. Sizing a deployment now takes a batch of rows and a click, and every customer gets an answer backed by a measurement of their own workload instead of an engineer's best guess.
## **The Decision Is a Measurement Problem**
A real recommendation is specific: at a given query rate, dataset size, and filter pattern, it names the replica count where p99 stops improving and what each step up costs. Getting there means sweeping across a grid of several query rates, several replica counts, on-demand versus dedicated, and one node type versus another, all built on an index shaped like the customer's real one.
When done from scratch, this takes tens to hundreds of runs, each with its own setup, import, request pattern, and teardown. Deployments got sized on intuition and prior experience, and the same trade-offs got re-litigated every time a new customer showed up with a familiar-looking workload. Automating that grid started with the simplest thing that could work.
## **What Got Built**
The first version automated what an engineer already did by hand: a script on an EC2 instance (a single AWS virtual machine), with someone watching it run. That worked for one-off questions. A sweep meant repeating up to hundreds of times the setup, load, and teardown by hand for every cell in the grid. Pinecone's own [VSB (Vector Search Bench)](https://github.com/pinecone-io/VSB) generated the load fine. Provisioning, capacity setup, and teardown around it were still manual, and that's what made a sweep slow.
A pipeline now wraps VSB with that missing automation: it provisions the index, configures capacity, runs the load, records results, and tears down, so a sweep runs unattended from a row in a database to a measured result.
A user describes the workload they want to test as one or more rows in a table fronted by a simple UI, and the system does the rest.
The end-to-end flow:
```json
{
"_key": "43dde79f8b63",
"_type": "htmlEmbed",
"code": {
"_type": "code",
"code": "\n\n\n\n\nBenchmarking Pipeline — One Session, End to End\n\n\n\n\n\n
\n
Benchmarking Pipeline
\n\n
\n \n
\n\n
\n \n Ready — press play to walk through one session.\n
\n\n
\n \n
\n
\n\n\n\n"
},
"title": "ascii diagram"
}
```
A **session** is a batch of rows submitted together — typically the full grid for one customer question. Triggering it launches a dispatcher that groups the rows by index shape and brings up **one EC2 worker per distinct index shape**. Each worker claims its rows one at a time and runs them serially.
That grouping is what keeps a sweep economical. Because an index is identified by its dimensions, vector count, and similarity metric, the **first row in a shape pays the one-time import cost, and every subsequent row reuses that index**, only reconfiguring capacity (say, changing the replica count) and re-running the benchmark. A 48-cell sweep over one dataset imports the data once and measures 48 times.
For heavy query loads, a single load-generating box can become the bottleneck before the index does. So a session can request multiple load generators. The worker coordinates them as a distributed fleet, so the target query rate is actually met rather than capped by one box's limits.
### **A workload is a set of knobs**
The whole point is to describe a customer's workload faithfully, so each row exposes the dimensions that actually move performance and cost:
- **Index shape.** Vector count, dimensions, distance metric, and which sparse model is in play for hybrid workloads.
- **Capacity.** On-demand (serverless) versus dedicated read nodes, including the node type and replica count, and a path to import cheaply on serverless and then switch to dedicated for the read benchmark.
- **Query load.** Target queries per second, duration, top_k, whether queries return values and metadata, and what metadata filters are applied to queries.
Each row also records what happened: achieved throughput, request counts and capacity limits, the full latency distribution, and recall. That's what a recommendation gets built on.
## **What This Has Meant for Customers**
The pipeline changed the kind of conversation possible with customers, in three ways.
**Cost.** The biggest win is that customers stop over-provisioning. Instead of buying headroom "to be safe," they provision exactly enough to hit the performance they're after. By sweeping a workload across replica counts, capacity modes, and node types, the pipeline pinpoints the configuration where the performance requirements are met and spend stops buying improvement. The customer gets the latency and throughput they need at the lowest configuration that delivers it, backed by a measurement of their actual workload.
**Performance.** Going the other direction, when a workload genuinely needs more replicas, a larger node type, a different capacity mode, the data shows exactly where the latency curve bends and what the next step buys. The recommendation comes with the data behind it, so it holds up three months later instead of getting re-litigated.
**Expectations.** Maybe the most valuable outcome is the least flashy. A customer about to scale, or about to change their architecture, can see what's going to happen _before_ they commit. Their workload gets benchmarked as it stands, the traffic they're growing into gets modeled, and the latency and throughput on the other side get laid out ahead of time. That turns a scaling event from a leap of faith into a planned change, with far fewer surprises in production.
The pipeline runs sweeps that used to take an engineer a week, and it runs them in the background from a batch of rows and a click. That time now goes into the next workload question worth answering, instead of re-running the last one by hand.