Key takeaways
- Volume testing increases the amount of DATA, not the number of users. That is what separates it from load testing.
- Most volume failures are queries that were fine against a small table and are not fine against a large one.
- Test at several data sizes rather than one. The shape of the curve is the finding, not any single number.
The quick answer
Volume testing measures how a system behaves as the volume of data it holds grows. The user count stays realistic; the database, the file store and the queues get large. It answers a question load testing cannot: does this application still work in two years, when the tables have a hundred times more rows in them?
What is volume testing in software testing?
Volume testing (sometimes called flood testing) is a performance test where the variable is stored data. You seed the system with a realistic quantity of records, then run the same operations you always run and watch what happens to response times, memory and disk.
The failures it finds are specific and they rarely appear in any other kind of test. A query with no index returns instantly against ten thousand rows and can take tens of seconds against ten million. A report that builds its result set in memory works until the result set no longer fits. A page that loads every record to count them is fast on an empty system and unusable on a full one.
None of these are visible in a load test, because a load test usually runs against a small seeded database. You can put a thousand concurrent users through an empty system and see excellent numbers.
Volume testing vs load testing vs stress testing
The three are routinely confused because all of them are performance tests. The difference is what you vary.
- Load testing varies the number of concurrent users at an expected level, and asks whether the system copes with the traffic you predict.
- Stress testing pushes the user count past that level to find where it breaks and how.
- Volume testing holds users roughly constant and varies the data, asking whether the system copes with the scale it will eventually hold.
A system can pass all the load testing you throw at it and still fail in production eighteen months later, because the load never changed and the data did. For the user-count side of the picture, see load testing vs stress testing and spike testing.
Volume testing is also often confused with scalability testing. Scalability testing asks how well the system grows when you add resources or traffic. Volume testing asks what happens to the same system as its data grows. The two overlap, but a volume test deliberately keeps the infrastructure and the traffic fixed.
What actually breaks under data volume
- Missing or unused indexes. The classic finding. Without a usable index the database reads the whole table, which costs nothing at ten thousand rows and a lot at ten million. Plans can also change as the table and its statistics grow, so a query that used an index on test data may not use it in production.
- Unbounded result sets. Anything that loads a whole table to filter or count it in application code.
- Pagination that counts. Showing “page 1 of N” requires counting every row, and that cost grows with the table.
- Report and export paths. These are usually written against a development dataset and never revisited.
- Storage that grows quietly. Logs, audit tables, soft-deleted rows and attachment stores fill disks that nobody is watching.
- Backup and restore windows. Restores get slower with data and only get tested during an incident.
A volume testing example
Take an online shop with an order history page and an admin search over all orders. Today the orders table holds about 50,000 rows. The business expects that to reach 2 million within two years.
A volume test for this system could look like this:
- Generate realistic orders at three sizes: 50,000 (today), 2 million (the two-year plan) and 10 million (well beyond it). Spread them over thousands of customers, many dates and several statuses, the way real orders are.
- At each size, run the same load test: a fixed number of virtual users browsing order history, searching orders in the admin and placing new orders.
- Compare the p95 response time of each operation across the three runs.
What a test like this tends to show: order history stays nearly flat because it is indexed by customer, so each page reads a few rows whatever the table size. The admin search, which filters on a column with no index, reads every row on every search, so its time grows with the whole table: 200 times the rows at 10 million means roughly 200 times the work, and worse once the table no longer fits in memory. It becomes unusable at the largest size. Placing an order gets slightly slower as the indexes it updates grow. That second line is the finding, and the fix is usually a single index or a rewritten query, found before a customer hits it.
How to run a volume test
Seed the system with data that looks like production, not with a million copies of the same record. Realistic distribution matters, because a table where every row has the same value indexes very differently from one where values are spread out.
Then run the same set of operations at several data sizes. Current volume, the volume you expect in a year, and something well beyond it. Keep the user load constant across all three so the only thing changing is the data.
Measure the operations users actually perform: the main list views, the search, the exports, the busiest API endpoints. Include at least one write path, because inserts slow down as indexes grow too.
Report percentiles rather than averages for each operation. A few very slow queries at the largest data size can hide inside a healthy-looking average; what response time is and how to measure it explains why p95 is the number to watch.
Volume testing tools
A volume test needs three things, and they are usually different tools:
- Something to generate data. Faker libraries (available for Python, JavaScript, Java and most other languages) produce realistic names, addresses and dates. Databases can also generate rows themselves, for example PostgreSQL’s
generate_series, which is much faster than inserting through the application. - Something to drive the operations. Apache JMeter and k6 scripts can run the same user journeys at a constant number of virtual users against each data size, and both can read CSV test data so each virtual user searches for different records instead of hitting the same cached row.
- Something to explain the result. The database’s own query plans (
EXPLAIN) and slow query log show which query stopped using an index. Server metrics show memory and disk growing with the data.
With LoadFocus you can run those JMeter or k6 scripts from the cloud with no load generators to manage, upload CSV or JSON data files for dynamic test data, and compare each run with the previous one, which is exactly the comparison a volume test is built on. To try the load side first, run a free load test against your site or a free API load test against an endpoint.
Reading the result
You are looking for the shape of the curve rather than any single measurement.
Flat or nearly flat
Operations that go through an index, such as fetching one record or one page of a list, should barely move as the table grows. This is what most user-facing operations should look like.
Linear growth
Response time rising in proportion to the data is predictable, and it is acceptable for operations that genuinely have to touch every row: a full export, a year-end report, a backup. For a search, a list page or a single-record view it is a finding, because it means the operation reads the whole table to return a few rows.
Non-linear growth
Response time rising faster than the data is the strongest signal. Typical causes are a sort with no supporting index, a join between two unindexed columns, or code that runs one query per row it has already loaded. It nearly always points at a specific query rather than at general slowness, and it is usually cheap to fix once identified.
A cliff
Performance that is level and then collapses at a particular size normally means something stopped fitting: an index no longer in memory, a cache no longer holding the working set, a result set no longer fitting in a buffer.
What good looks like
A system that passes volume testing has response times that grow predictably and slowly with data, and no operation whose cost is proportional to total table size when it should be proportional to the page being shown. The practical target is that the curve at ten times today’s data is still inside your acceptable response time, because that is the horizon you can plan around.
Frequently Asked Questions
Is volume testing the same as load testing?
No. Load testing varies the number of concurrent users; volume testing varies the amount of stored data. A system can pass one and fail the other, which is why both exist.
How much data should I test with?
At least the volume you expect within your planning horizon, and ideally several multiples so you can see the shape of the curve. One measurement at one size tells you the current cost, not how it grows.
Can I use copied production data?
Only if it is anonymised properly. Real records in a test environment are a data protection problem, and test environments are usually less protected than production. Generated data with a realistic distribution avoids the issue.
What is an example of volume testing?
Seeding an orders table at today’s size, the size expected in two years and a much larger size, then running the same load test at each size and comparing response times. An operation whose time grows with the whole table when it should not, such as a search on an unindexed column, is the typical finding.
What tools are used for volume testing?
A data generator such as a Faker library or the database’s own functions, a load testing tool such as JMeter or k6 to run the same operations at each data size, and the database’s query plans and slow query log to explain what got slower.
Is volume testing the same as soak testing?
No. Soak testing, also called endurance testing, holds a normal load for many hours to find problems that build up over time, such as memory leaks and connection pools that slowly run out. Volume testing changes the amount of stored data and compares short runs at each size. A long soak test does add data as it runs, but rarely enough to show how the system behaves at several times today’s volume.
How is volume testing different from scalability testing?
Scalability testing checks how the system performs as you add traffic or resources. Volume testing keeps traffic and infrastructure fixed and grows only the stored data, to find operations whose cost rises with the size of the data.
Sources
- Set Returning Functions (
generate_series) and EXPLAIN, PostgreSQL documentation (October 2026)
