---
title: "What Is Volume Testing? Definition and Examples | Evaluat"
description: "Volume testing checks that your site stays fast when its data grows to production size. What it is, how it differs from load testing, and how to run one."
url: "https://www.evaluat.com/blog/what-is-volume-testing"
last_modified: "2026-10-19"
---

[Blog](https://www.evaluat.com/blog) [Testing Types](https://www.evaluat.com/blog/category/testing-types)

# What is volume testing?

Your test database has 2,000 products. Production has 400,000. Volume testing is the test for that gap. It holds traffic at normal levels and grows the data instead (the catalogue, the order history, the search index) to check that pages, searches and back-office jobs stay fast at the size your shop really is.

Written by: [Ahmad Farzan](https://www.evaluat.com/authors/ahmad-farzan) · 19 October 2026

[Beginner's guide](https://www.evaluat.com/blog/beginners-guide) Part 13Types of tests

![The same shopping journey run at the same traffic against a staging store with 2,000 products and a full-size store with 400,000 products, drawn as paired bars of 95th percentile response time. The filtered category page takes 0.9 seconds on 2,000 products and 3.8 seconds on 400,000. Search takes 0.6 seconds on 2,000 products and 2.4 seconds on 400,000. Nothing changed but the data.](https://www.evaluat.com/blog/what-is-volume-testing-cover.svg)

Summary

Volume testing is a type of performance testing that checks how a system behaves when its data is as large as it is in production, or as large as it will be. Most performance tests change the amount of traffic. A volume test keeps traffic at a normal level and changes the amount of data instead, such as the number of products in the catalogue, the years of order history, or the size of the search index. It matters because test environments are usually small. A store that has two thousand products in staging may have four hundred thousand in production, and databases do not slow down in a straight line as tables grow. A query that is instant on a small table can change its plan, read far more rows, or page through thousands of results on a large one. Background work grows too, such as reindexing, imports and sitemaps. To run a volume test, measure how big your production data is, decide how big it will be at your next peak, build a test environment at that size with generated or properly masked data, and run the same customer journeys against both the small and the full-size data. The difference between the two runs is what your data costs you.

Listen to this article · 1:14

[Download the audio summary (MP3)](https://www.evaluat.com/blog/audio/what-is-volume-testing.mp3)

Key takeaways

- Volume testing holds traffic at normal levels and grows the data to production size or beyond.
- Test environments are usually far smaller than production, so data-size problems stay hidden until launch.
- Databases can change query plans as tables grow, so results on a small table do not predict a large one.
- Grow every table that grows in real life: products, variants, customers, orders, search index and logs.
- Run the same journeys against small and full-size data, and time the back-office jobs as well.

## What is volume testing?

Volume testing is a type of performance testing that checks how a system behaves when it holds large amounts of data, as much as production holds now or will at its next peak. Traffic stays at a normal level. The data grows instead: more products, more orders, a bigger search index. The question is whether size alone slows things down.

The international software testing standard puts it formally. The 2013 edition of ISO/IEC/IEEE 29119-1 describes volume testing as testing [to evaluate the capability of the test item to process specified volumes of data (usually at or near maximum specified capacity)](https://www.imbus.de/en/glossar/term/volume-testing), in terms of throughput capacity, storage capacity or both. This guide uses the narrower, practical meaning most web teams need: hold the traffic steady, scale the stored data.

A library is a fair picture. Finding one book on a shelf of 200 takes seconds, with or without a catalogue. Finding it among 400,000 takes seconds with a good catalogue and days without one. The librarian has not got slower. The collection has got bigger, and every shortcut that did not matter at 200 books suddenly matters a great deal.

[Part 3 of this guide](https://www.evaluat.com/blog/types-of-performance-testing) introduced volume testing as one of the supporting types. This part takes it apart: why data size changes performance, what to grow, and how to run the test.

## Why does volume testing matter?

Because test environments are usually much smaller than production, so the problems that come with size stay hidden until real data meets them. A page that is instant in staging can crawl in production with the same code, the same servers and the same traffic. The only difference is the number of rows behind it.

The gap is common, even at engineering-led companies. GitLab’s own design document for database testing noted that its staging database was [less than 5% of the production database size as of January 2021](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/database_testing/), and that the team often saw migrations succeed in staging but then fail in production due to query timeouts.

How teams fill their test environments varies widely. In Redgate’s 2024 survey of 3,849 database professionals, asked which data they supply to development and test environments, [47% use synthetic data, 43% use a full-size production backup and 28% use a subset of production data](https://www.red-gate.com/solutions/state-of-database-landscape/2024/security-and-testing/), with many using more than one. Synthetic data and subsets are fine, as long as someone checks that they are big enough.

Large catalogues are not rare either. Store Leads’ October 2026 count of live Shopify stores shows [136,495 stores selling 1,000 to 4,999 products](https://storeleads.app/reports/shopify), and more than 25,000 selling 10,000 or more. Per-record size counts too: in October 2025 Shopify raised its limit to [2,048 variants per product](https://shopify.dev/changelog/the-product-variant-limit-is-now-2048-for-all-merchants), warning that apps not on its current product APIs may have a downgraded or broken experience with more than 100 variants. The same app, twenty times the data, a different result.

## Volume testing vs load testing: what is the difference?

A load test changes the amount of traffic and keeps the data the same. A volume test changes the amount of data and keeps traffic at a normal level. They answer different questions: whether the site copes with more people, and whether it copes with being bigger. A load test is only as trustworthy as the data behind it.

| Type             | What grows                                  | What stays fixed | The question it answers           |
| ---------------- | ------------------------------------------- | ---------------- | --------------------------------- |
| Load testing     | Users and requests, up to the expected peak | Data             | Does it hold at expected traffic? |
| Stress testing   | Traffic past the peak                       | Data             | Where does it break, and how?     |
| Soak testing     | Time                                        | Traffic          | Does it degrade over hours?       |
| Capacity testing | Traffic in steps                            | Targets          | What is the usable ceiling?       |
| Volume testing   | Stored data, to production size or beyond   | Traffic          | Does size alone slow it down?     |

The types blur in practice. A [capacity test](https://www.evaluat.com/blog/what-is-capacity-testing) run on a small database gives you a capacity that production will never reach, and a [soak test](https://www.evaluat.com/blog/soak-testing) can be partly a volume test, because logs and tables grow during the run. The ISTQB performance testing syllabus lists [growth of the file repository, and unexpected database growth](https://www.istqb.org/wp-content/uploads/2024/11/ISTQB-CT-PT_Syllabus_v1.0_2018.pdf) among the causes of response times that degrade over time. Volume testing is the habit of treating data size as a variable you control, not an accident of whichever environment you test in.

## Why does more data make a website slower?

Because much of the work behind a page grows with the data. Queries that read whole tables read more rows, databases change their plans as tables grow, pages deep in a long list cost more to find, and background jobs that touch every product take longer. None of it shows on a small database.

### Queries that read whole tables

A query without a suitable index reads every row. MySQL’s documentation is direct about it: [the larger the table, the more this costs](https://dev.mysql.com/doc/refman/8.4/en/mysql-indexes.html). On a table of 2,000 products a full read is cheap enough that nobody notices the missing index. On 400,000 it is two hundred times the work, on every page view that runs it.

### The database changes its plan

Databases choose how to run each query based on the size of the tables. PostgreSQL’s documentation warns that [results on a toy-sized table cannot be assumed to apply to large tables](https://www.postgresql.org/docs/current/using-explain.html), because the planner’s cost estimates are not linear and it may choose a different plan. A query that looked efficient in staging may run a different way in production. You only find out by testing at production size.

### Deep pages and long lists

Category pages, search results and admin grids show one page of results at a time, and the common way to fetch page 50 is to skip the first 49 pages. Markus Winand, author of *Use The Index, Luke*, explains the cost: [the database must count all rows from the beginning until it reaches the requested page](https://use-the-index-luke.com/sql/partial-results/fetch-next-page). A category with 40 products never goes deep. One with 40,000 does.

### Background jobs and batch windows

Some of the work is not on any page. Adobe notes that [reindexing all indexers can take a long time for stores with large numbers of products](https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cli/manage-indexers), customers and categories. Sitemaps hit hard limits: Google says [all formats limit a single sitemap to 50MB (uncompressed) or 50,000 URLs](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap), so 400,000 product pages need at least eight files where 2,000 needed one. The ISTQB syllabus names the failure plainly: [batch processing is unable to complete](https://www.istqb.org/wp-content/uploads/2024/11/ISTQB-CT-PT_Syllabus_v1.0_2018.pdf) before online processing is needed.

### Tables that were designed small

Some designs are fine until the data grows. Moshe Tsur, a principal software engineer at Harness, wrote in 2026 that [when you have thousands of rows, queries are fast, and the duplication barely matters](https://www.harness.io/blog/lessons-from-refactoring-at-scale), and that at millions of rows the team’s queries were roughly ten times slower than they needed to be. WooCommerce rebuilt its order storage for the same reason. On a test store with about 400,000 orders, its benchmark found that with the new tables [this query to get all orders for a customer is now 40x faster](https://developer.woocommerce.com/2023/03/17/performance-benchmarking-for-woocommerce-hpos/).

## What data should a volume test grow?

Every table that grows in real life, not just the catalogue. Products and variants are the obvious ones, but order history, customers, baskets left behind, search indexes and logs grow too, and each slows different pages. Size each one to what production will hold at your next peak, not to what is easy to generate.

Adobe’s performance toolkit for Magento is a useful yardstick, because its standard profiles span the range from a test store to a large catalogue.

| Toolkit profile | Simple products | Categories | Customers | Orders  |
| --------------- | --------------- | ---------- | --------- | ------- |
| Small           | 800             | 30         | 200       | 80      |
| Medium          | 24,000          | 300        | 2,000     | 50,000  |
| Large           | 300,000         | 3,000      | 5,000     | 100,000 |
| Extra large     | 600,000         | 6,000      | 10,000    | 150,000 |

Source: [Adobe Commerce performance toolkit profiles](https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cli/generate-data). A store testing on something like the small profile while production looks like the large one is testing a different shop.

Beyond row counts, check the shape of the data:

- **Catalogue**: products, variants per product, attributes and options, and products per category.
- **Customers and orders**: years of history, not a few weeks, and customers with many orders.
- **Search**: an index built from the full catalogue, searched with many different terms.
- **Leftovers**: abandoned baskets, sessions, logs and queue tables that nobody cleans.
- **Prices and rules**: customer groups, price rules and stores, which multiply some indexes.

## How do you run a volume test?

Measure production, decide the size you are testing for, build an environment at that size, and run the same customer journeys at normal traffic against small and full-size data. The difference between the two runs is what your data costs you. Then time the back-office jobs on the full-size data as well.

1. **Measure production.** Count the rows in your largest tables and note how fast each grows per month.
2. **Pick the target size.** Today’s size plus growth to your next peak, with a margin for known plans such as a new range or a marketplace feed.
3. **Build the dataset.** Generate it, for example with Adobe’s `bin/magento setup:perf:generate-fixtures` or a Faker library, or mask a production copy. The ISTQB syllabus warns that masking [may not have the same data characteristics as seen in real-world use](https://www.istqb.org/wp-content/uploads/2024/11/ISTQB-CT-PT_Syllabus_v1.0_2018.pdf), so check the result looks like production.
4. **Run the same journeys twice.** Use identical traffic against the small and the full-size data, and compare response times page by page.
5. **Time the jobs.** Reindexing, imports, exports, sitemap generation and backups, on the full-size data.
6. **Read the query plans.** Run `EXPLAIN` on the slowest queries at full size, where the planner may choose differently.

Be careful with real customer data. The UK Information Commissioner’s Office states that [pseudonymised personal data is in scope of data protection law](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/anonymisation/pseudonymisation/), so a copy with names swapped out is still personal data. Synthetic data at production size avoids the question.

Here is a worked example. An example shop has 2,000 products in staging and 400,000 in production. It runs the same journey, home, category, filter, search, product, basket, with 100 virtual users against both. Most pages barely move. The filtered category page goes from a 95th percentile of 0.9 seconds to 3.8 seconds, and search from 0.6 to 2.4. `EXPLAIN` on the full-size data shows the filter query reading every product, because one attribute used in filters has no index. On 2,000 rows nobody could have seen it.

## Common mistakes with volume testing

Most volume testing mistakes come from growing the wrong thing, or growing it once.

- **Testing on sample data.** Demo catalogues are tiny. They prove the code runs, not that it runs at your size.
- **Growing products but not orders.** Order history, customers and logs slow checkout, accounts and the admin.
- **Copying production without care.** Masked or not, a production copy carries personal data and needs the same protection.
- **Forgetting the back office.** Reindexes and imports that overrun into trading hours hurt customers too.
- **Testing once.** Data grows every month. Re-run the test before each peak.

## How Evaluat handles volume testing

Evaluat does not create your data. The volume lives in the environment you test, so you build the full-size store and Evaluat measures what shoppers would experience in it. Build a scenario once. Use it everywhere. Run the same journey against the small staging store and the full-size one, then compare the two reports’ response times, time to first byte and Core Web Vitals per URL.

Datasets give each virtual user its own search terms, logins and form inputs, so searches reach the long tail of a big catalogue rather than repeating one term the cache already holds. When a page slows only on the large store, open a session from the slow period: the network log shows which request took the time, such as a filter call or a search request, and the session video shows what the shopper was looking at while it waited.

The boundary is worth stating. Evaluat measures pages and journeys from the outside, from the region closest to your customers. It cannot time your reindexes and imports or read your query plans; your database tools do that. Together they tell you whether your shop is fast at the size it really is.

Data grows quietly, a few thousand rows a week, until a page that was always fine is not. Test at the size you will be at your next peak, not the size your staging store happens to be.

Test in real browsers. Debug in real sessions. [Book a demo](https://www.evaluat.com/demo?intent=performance) to run your journeys against production-sized data.

[Previous · Part 12Time to First Byte (TTFB), explained](https://www.evaluat.com/blog/time-to-first-byte) [Next · Part 14What a CDN does (and does not) do for your site under load](https://www.evaluat.com/blog/what-is-a-cdn)

![Ahmad Farzan, Founder at Evaluat](https://www.evaluat.com/authors/ahmad-farzan.jpg)

About the author

[Ahmad Farzan](https://www.evaluat.com/authors/ahmad-farzan) · Founder at Evaluat

Founder of Evaluat. Has spent years building and load-testing Adobe Commerce and Magento storefronts, and built Evaluat to test sites the way real browsers actually hit them.

[Ahmad Farzan on LinkedIn](https://www.linkedin.com/in/ahmadfarzan/) [Ahmad Farzan on GitHub](https://github.com/farzanahmad)

[More from Ahmad](https://www.evaluat.com/authors/ahmad-farzan)

Common questions

## FAQ

### What is volume testing in software testing?

Volume testing is a type of performance testing that checks how a system performs when it holds large volumes of data, usually at or near the maximum it is expected to hold. It answers whether pages, searches and jobs stay fast as the data grows, rather than whether the system copes with more users.

### What is an example of volume testing?

An online shop with 2,000 products in staging and 400,000 in production builds a test store with 400,000 products, 150,000 orders and a full-size search index. It then runs the same browsing and checkout journeys at normal traffic against both stores and compares response times. Pages that slow down only on the large store have a data-volume problem.

### What is the difference between volume testing and load testing?

A load test changes the number of users or requests and keeps the data the same. A volume test changes the amount of data and keeps traffic at a normal level. The two combine well, and a load test run on production-sized data is more trustworthy than one run on a small test database.

### What is the difference between volume testing and stress testing?

Stress testing pushes traffic past the expected peak to find where and how a system breaks. Volume testing keeps traffic normal and grows the data to find where size alone slows the system. One looks for the breaking point under load, the other for the slowdown that comes with growth.

### Is volume testing a type of performance testing?

Yes. The 2013 edition of the ISO/IEC/IEEE 29119-1 software testing standard defines it as a type of performance efficiency testing, alongside load, stress, endurance and capacity testing. It is often skipped because most load testing tools focus on traffic, not data.

### Can I use production data for a volume test?

Only with care. A copy of production contains personal data, and UK guidance is clear that pseudonymised personal data is still within data protection law. Many teams generate synthetic data at production size instead, or mask a copy, accepting that masking can change how the data behaves.

### How much data should a volume test use?

At least as much as production holds today, and ideally as much as it will hold at your next peak. Measure your largest tables, work out their monthly growth, and project forward to the event you are preparing for, adding a margin for catalogue or campaign growth you already know about.

### What tools are used for volume testing?

Two kinds. A data generator builds the large dataset, such as Adobe's performance toolkit for Magento, Faker libraries, or database tools that create rows in bulk. A performance testing tool then runs realistic journeys against it and measures response times, so the same test can be compared on small and large data.

Related reading

## More from the blog

[![The four main types of load testing as four traffic shapes: load testing ramps to expected traffic and holds; stress testing climbs until the system breaks; spike testing jumps to a sudden surge and drops back; soak testing holds a steady load for hours. Each shape answers a different question.](https://www.evaluat.com/blog/types-of-performance-testing-cover.svg)](https://www.evaluat.com/blog/types-of-performance-testing)

### [The types of performance testing, and when to use each](https://www.evaluat.com/blog/types-of-performance-testing)

[Load, stress, spike, soak: the names get used interchangeably, but each test answers a different question about your site. This guide maps every major type of performance testing to the question it answers and the traffic shape it uses, in one table, with an honest order to run them in. Start with the question, and the right test picks itself.](https://www.evaluat.com/blog/types-of-performance-testing)

[Ahmad Farzan · 9 September 2026](https://www.evaluat.com/blog/types-of-performance-testing)

[![A capacity test steps the load up in plateaus, from 500 to 1,750 virtual users, while the 95th percentile response time is read at each step. Response time stays under the two second target up to 1,250 users, which is the usable ceiling, crosses the target at 1,500, and the site only breaks at 1,750. Capacity is the last step that still meets the target, not the breaking point.](https://www.evaluat.com/blog/what-is-capacity-testing-cover.svg)](https://www.evaluat.com/blog/what-is-capacity-testing)

### [What is capacity testing?](https://www.evaluat.com/blog/what-is-capacity-testing)

[Most teams can tell you when their site falls over. Far fewer can tell you when it stops being good enough, and that second number is the one customers feel. Capacity testing, in performance testing, finds it. It measures how many users your site can serve while still meeting the speed and error targets you set in advance.](https://www.evaluat.com/blog/what-is-capacity-testing)

[Ahmad Farzan · 18 September 2026](https://www.evaluat.com/blog/what-is-capacity-testing)

[![Response time chart for the same checkout: at one user the page answers in under a second; as concurrent users approach 3,000 the curve bends and the same page takes eight seconds. Load testing measures that curve before real traffic does.](https://www.evaluat.com/blog/what-is-load-testing-cover.svg)](https://www.evaluat.com/blog/what-is-load-testing)

### [What is load testing?](https://www.evaluat.com/blog/what-is-load-testing)

[Load testing tells you what happens to your site when real traffic shows up at once. This guide explains what it is, why slow pages cost conversions, how a test actually runs, and how to size your first run, with no prior testing background assumed.](https://www.evaluat.com/blog/what-is-load-testing)

[Ahmad Farzan · 12 July 2026](https://www.evaluat.com/blog/what-is-load-testing)

See it on your site

Test in real browsers.\
Debug in real sessions.

## Want to see this measured on your app?

30 minutes. We build a scenario on your real customer journey, run a small test, and walk you through the report.

[Book a demo](https://www.evaluat.com/demo?intent=performance) [How it works](https://www.evaluat.com/how-it-works)