What Is Volume Testing?
Short answer
Volume testing asks whether a journey still completes—fast enough and without errors—when the data already in the system is large: 100k invoices, a fat multi-tenant catalog, years of audit logs. You keep concurrency low (often 1–few users) and vary dataset size. That is the opposite control from load testing, which varies users against a typical dataset. Mixing both in one script hides whether you have an N+1 query or a saturated thread pool.
Part of Performance testing guides.
Who this is for
Product teams whose day-one demo is fast and month-six tenant is not: reports, search, exports, inbox views, admin tables, billing history—anything that scales with rows stored, not shoppers on the site right now.
Volume vs load (keep the axes separate)
| Load testing | Volume testing | |
|---|---|---|
| Question | Can N users finish this journey together? | Can one (or few) users finish it when M records already exist? |
| You change | VUs / arrival / duration (profiles) | Dataset manifest (cardinality, bytes, object counts) |
| You hold still | Typical data shape | Typical concurrent users (often smoke-level) |
| Failures you find | Queueing, pool exhaustion, lock contention, timeouts | Missing indexes, N+1, unbounded SELECT *, in-memory maps, pagination that loads everything |
| Wrong move | “Make it heavier” by stuffing the DB and cranking VUs | Calling a 200 VU run “volume” because the JSON body is large |
A checkout that is fine at 50 VUs on an empty shop can still time out for one finance user exporting a year of invoices. Those are different bugs and need different seeds.
When volume testing is the right test
Plan a volume journey when the scenario is data-size sensitive:
- List / grid / inbox pages that query “everything for this tenant”
- Search and filters over growing catalogs
- CSV / PDF / report generation
- Billing, ledger, audit, and compliance log views
- Permission checks that join wide access-control tables
- “Open tenant settings” that hydrates the whole org graph
Create-perf-tests classifies journeys as load, volume, or both—and asks you before treating a path as volume-sensitive. Agents must not silently assume “bigger traffic” covers data growth.
How to design a volume test
- Version a dataset manifest — record counts, object types, and a seed command. No production dumps with secrets.
- Seed before the run —
k6/scripts/seed.shwith an explicitSEED_COMMANDorSEED_URL. Tear down generated rows after. - Keep concurrency honest — a volume profile is not a load profile with a bigger JSON file. One or few VUs is the point.
- Assert on the expensive path — first page of a 100k-row table, export job completion, search with a selective filter and a common prefix.
- Watch the same metrics — p95 on that path, 5xx from query timeouts, 4xx from “payload too large” or pagination bugs.
- Compare like for like — overlay only runs that share dataset version as a comparison key. A 1k-row seed vs a 100k-row seed is incomparable.
TestChimp treats dataset / version as a first-class comparison key next to environment and profile. Overlaying mismatched datasets is marked incomparable, never a silent pass. See comparison keys.
Failures volume tests catch that load tests miss
- Missing index on
tenant_id + created_atthat never showed up with 12 demo rows - N+1 ORM behind a list that “looks fine” in SmartTests
- Unbounded hydration (
SELECT *, loading 50k rows into memory to render 20) - Count(*) on an unpartitioned table for a badge that used to be instant
- Export that holds an open transaction until the file is fully written
Coding agents are unusually good at core functionality on a small fixture. Volume testing is how you put a leash on “it works on my seeded demo.”
How TestChimp runs volume tests
- Tag the journey
testTypes: ['volume']andvolumeKind: '<kind>'(optionally also'load'if you will run separate profiles—not one mixed hammer) - Put cardinality in
k6/datasets/volume-<kind>-{10,50,100}.json; keep VUs ink6/profiles/volume.jsat 1 (still not a 200 VU load profile) - Staircases: seed distinct 10% / 50% / 100% tenants, then one
k6 runviak6/scripts/run.sh journeys/foo.jsthat holds 1 VU at each size and emitsvolume_sizeso Executions charts p95 against data size, not VUs. Ingest the peak (-100) dataset id. Do not run three separate 1-VU jobs. - Execute via wrappers so ingest records dataset id (peak/target), git SHA, and metrics
- After a release cut, related volume journeys for data-heavy screens in the git range run with
/testchimp run-perf-testsand show on the release Performance Tests panel
Product walkthrough: organization — load vs volume.
Related
Frequently asked questions
What is volume testing in software?
Volume testing checks system behavior with a large amount of data already present—records, files, or events—while concurrency stays low. The goal is to find data-size failures (indexes, N+1, unbounded queries) that load tests with a small database will not show.
Is volume testing the same as load testing?
No. Load testing varies concurrent users. Volume testing varies dataset size. Doing both in one run makes it unclear which axis caused the p95 spike or 5xx errors.
Is volume testing the same as soak testing?
No. Soak (endurance) holds realistic load for a long time to find leaks and queue backup. Volume is about how much data exists before the session starts, not how long the test lasts.
How large should the volume dataset be?
Large enough to exercise the real query plan (indexes, pagination) for a mature tenant—not a production clone and not “whatever fits in RAM on a laptop.” Size is a policy decision; telemetry is only a relative ranking signal for which journeys need a volume variant.
How does TestChimp support volume testing?
Journeys can be classified as volume with volumeKind, seeded from versioned 10/50/100 manifests, run once through k6/scripts/run.sh so Executions charts volume_size, ingested with the peak dataset as a comparison key, and compared across releases. Agents must confirm volume-sensitive scenarios with you rather than silently raising VUs.
Test the tenant that already has history
Use `/testchimp create-perf-tests` to classify data-heavy scenarios as volume journeys, seed a versioned dataset, and compare p95 against the last release on the same manifest.