What is Volume Testing?

What is volume testing?

Volume testing is a performance test where the system is subjected to large volumes of data, and the data size is the variable you change. User numbers stay realistic while databases, file stores and queues grow, so you can see what happens to response time, memory and disk. It is sometimes called flood testing.

It is a data-path discipline, not a concurrency one. A single user exporting five years of orders is already a volume test.

For a worked example, the tools and how to read the curve, see volume testing in software testing on the LoadFocus blog.

Volume testing vs load testing

Both are performance tests, but they vary different things. A load test fixes the data and scales concurrency: what happens when 5,000 users hit a normally sized system? A volume test fixes concurrency and scales the data: what happens when the same system holds a hundred times more rows? Passing one says little about the other. A system can pass every load test against a small staging database and still fail in production, where the tables are far larger.

Two neighbours are easy to confuse with it. Capacity testing looks for the maximum load the system carries, and scalability testing asks how it behaves as you add resources or traffic. A volume test keeps infrastructure and traffic fixed and grows only the data.

How a volume test works

1. Build realistic data at several sizes. Restore a recent backup to a test copy, or generate records with realistic spread (many customers, dates and statuses). Remove personal data first.
2. Run the same workload at each size. A fixed number of virtual users, the same operations.
3. Compare the curves. Plot p95 response time, memory and disk use against data size. A number that grows faster than the data is the finding.

Example (hypothetical numbers): an online shop has 50,000 orders and expects 2 million within two years. Test at 50,000, 2 million and 10 million orders. At each size, run the same mix of order history views, admin searches and new orders, and compare the p95 of each operation. If the admin search stays flat until 2 million and then jumps, you have found the size at which its query stops using an index.

What breaks under data volume

• Missing or unused indexes. A query that is instant at 10,000 rows can scan the whole table at 10 million, and query plans can change as tables grow.
• Unbounded results. Code that loads a whole table to filter or count it in memory.
• Pagination and counting. "Page 1 of N" requires counting rows, and deep offsets get slower with every page.
• Exports, reports and migrations. Usually written against a development dataset and never revisited.
• Queues. A deep backlog or one poison message can stall consumers that never saw more than a few items.
• Backups, restores and index rebuilds. Their duration grows with data and is often only discovered during an incident.

Common mistakes

• Testing at one size. One data point cannot show a curve. Use at least three sizes.
• Unrealistic data. Millions of identical rows hit the cache and the index very differently from real data.
• Ignoring the future. Test the size you expect in one or two years, not only today's.
• Only the happy path. Test the slow paths: reports, exports, bulk imports, background jobs.
• Using production data unredacted. Mask personal data in any copy.

Volume testing, monitoring and LoadFocus

LoadFocus supplies the traffic, not the data: you prepare the large dataset in your test environment, then run a fixed-size load test against it with k6 or JMeter and compare response-time percentiles between runs. Keep the user count the same each time so only the data changes. Volume testing is separate from soak testing, which holds load for hours to find leaks: see endurance and soak testing. After release, API monitoring shows whether the endpoints you tested stay fast as real data grows.

FAQ

What is the difference between volume testing and load testing?

Volume testing grows the amount of data while keeping users constant. Load testing grows the number of concurrent users while keeping data constant.

Is volume testing the same as stress testing?

No. Stress testing pushes user load past its limit to find where the system breaks. Volume testing pushes data size, and the failures are different: slow queries, memory pressure, long jobs.

How much data should I test with?

Use your current production size as the lowest point, your expected size in one to two years as the middle, and a larger figure as a margin. Compare the results across sizes rather than judging one run.

Can I run a volume test in production?

It is safer on a copy with production-sized data, with personal data masked. Filling production with test data risks corrupting real records and reports.