What is volume testing?

Volume testing checks how your software performs when it holds and processes large amounts of data. We fill the database, files and queues to production size or beyond, then measure how queries, reports, imports, search and batch jobs behave.

Is volume testing the same as flood testing?

Yes. Flood testing is another name sometimes used for it. Both mean testing with a very large amount of data rather than a large number of users.

How is volume testing different from load testing?

Load testing increases the number of users and requests. Volume testing increases the amount of data. A system can handle many users on a small database and still struggle with only a few users on a large one.

How is volume testing different from scalability testing?

Scalability testing measures how performance changes as you add load or capacity. Volume testing focuses on data size. The two often work together when both traffic and data are growing.

When should we do volume testing?

Before your data is expected to grow significantly, before onboarding a large customer, before a data migration or database upgrade, and when reports, search or exports start getting slower.

Do you use our production data?

Not by default. We generate realistic test data with the same shape and distribution as yours, so no personal or customer data has to leave production. If you prefer to use masked production data, we can plan around that instead.

How much data do you test with?

Usually your current production size first, then your projected size in one to two years, and sometimes more. We agree the sizes with you based on your growth figures.

What problems does volume testing find?

Slow or unindexed queries, reports and exports that time out or run out of memory, imports that overrun or fail part-way, search that slows as the index grows, batch jobs that miss their window, and migrations that take longer than planned.

Can you test a data migration before we run it?

Yes. We rehearse it on full production-sized data, time it, check record counts and data integrity afterwards, and measure how the new system performs with the migrated data.

Which databases can you volume test?

We test the database your product already uses, relational or NoSQL, and analyse slow queries with its own query plans and monitoring.

Which volume testing tools do you use?

JMeter and k6 most often, plus Gatling, Locust, LoadRunner, NeoLoad and BlazeMeter to run journeys and jobs. For metrics we use Grafana, Prometheus, New Relic, Datadog and AWS CloudWatch. We can also work in the tools you already have.

What do you need from us?

A test environment with enough storage for the test data, your schema and key journeys, your current data sizes and growth figures, monitoring and database access, and a contact who knows your data model. We sign your NDA before we get access.

How long does a volume testing project take?

As a general guide, two to four weeks. Generating large, realistic data sets takes part of that time, especially for very large or complex schemas. You get a timeline after the first call.

How much does volume testing cost?

It depends on the data sizes, the number of journeys and jobs, and how many rounds you need. A scoped volume test is usually quoted as a fixed price, and ongoing checks as a monthly plan. Try our cost utility for a first estimate, or ask us for a quote.

Volume Testing Services

Your product was built and tested with a few thousand records. Your customers will give it millions. Volume testing shows what happens to search, reports, imports and the database when the data gets big.

We load your system with production-sized and future data volumes, then run real journeys, imports, exports and batch jobs against it. You see which queries slow down, which jobs overrun, which screens time out, and at what data size each problem starts.

Get in touch Plan your volume test

Production-sized test data
Queries, imports and reports timed
JMeter, k6, Gatling and more
Free one-week POC

What we do

Large databasesBig tables Reports & exportsThe slowest screens Bulk importsData coming in Search & indexingFinding things fast Batch jobsJobs that must finish Message volumeData in motion Files & storageBig files, many files Data migrationMoving it all

[ Why volume testing ]

Most test environments are far too small to show the problem

A table with ten thousand rows hides almost everything. A query without the right index returns instantly, a report that loads every record into memory works fine, and an export finishes before anyone notices. At ten million rows the same code times out, runs out of memory or locks the table for everyone else. Production gets there gradually, so the slowdown arrives quietly, one customer complaint at a time. Volume testing gets there on purpose: we create the data your system will hold, then measure what still works and what doesn’t.

Testing high user traffic rather than large data? See load testing services →

Know your data limits

The data size at which each query, report or job stops meeting its target.

Reports and search that stay fast

Slow queries and missing indexes found before your biggest customers find them.

Imports and migrations that finish

Bulk loads, exports and migrations timed with real volumes, not samples.

Plan storage and archiving

How fast data grows, and when archiving or partitioning will be needed.

[ What we test ]

Eight places where big data slows things down

From one slow query on a large table to a full migration rehearsal. Each card lists what we test, when you need it and the problem it prevents.

Large database testing

Millions of rows

We fill your database to production size, or beyond, and measure the queries your product depends on.

What we test

Query times at current and future table sizes
Indexes used, missing or ignored
Locking and contention on large tables
Paging, sorting and filtering on big result sets

When you need it

Before data grows significantly, and after schema changes.

The problem it preventsA screen that loads in a second today and in a minute next year

Reports, dashboards & exports

Heavy reads

Reports and exports read the most data at once. We test them at full volume, including your largest customers’ accounts.

What we test

Report and dashboard load times on large accounts
CSV, Excel and PDF exports of big data sets
Memory used while reports are built
Timeouts and limits on long-running requests

When you need it

When reporting is a selling point, or big customers complain first.

The problem it preventsReports that time out for exactly the customers who pay most

Bulk imports & data loads

Files, APIs, ETL

Imports of thousands or millions of records through files, APIs or ETL jobs, checked for speed, completeness and side effects.

What we test

Large CSV, Excel and API bulk imports
Validation, duplicates and error handling at volume
The effect of imports on people using the product
Partial failures and safe re-runs

When you need it

Before onboarding large customers or adding new data sources.

The problem it preventsAn onboarding import that runs all night and fails at 90%

Search & indexing at volume

Search engines, indexes

Search that is quick on a small index can slow down sharply as documents pile up. We test search and indexing at the size you’ll reach.

What we test

Search response times as the index grows
Indexing speed and lag for new and changed data
Filters and sorting on large result sets
Re-indexing time after changes

When you need it

For products where search is a main journey.

The problem it preventsSearch results that arrive late, or show out-of-date data

Batch jobs & scheduled processing

Nightly, hourly

Nightly billing, reconciliation, notification and clean-up jobs, run against full data volumes to check they finish inside their window.

What we test

Job duration at current and future volumes
Batch size, chunking and memory use
Jobs overlapping each other or user traffic
Restart and recovery after a failed run

When you need it

When jobs run on growing data with a fixed deadline.

The problem it preventsA nightly job that’s still running when users arrive

Message & event volume

Queues, streams, logs

High volumes of messages, events and logs flowing through queues and streams, checked for throughput, order and backlog.

What we test

Millions of messages through Kafka, RabbitMQ or SQS
Consumer throughput and lag under sustained volume
Large message payloads and batching
Event and log storage growth

When you need it

For event-driven systems, analytics pipelines and integrations.

The problem it preventsA backlog that builds silently until data is hours late

Files, uploads & storage

Documents, media

Large files and very many files: uploads, downloads, processing and storage, tested at the sizes your users really send.

What we test

Large file uploads and downloads
Thousands of files per account or folder
Processing such as resizing, parsing and conversion
Storage growth and clean-up

When you need it

For document, media and file-heavy products.

The problem it preventsUploads that fail above a size nobody tested

Data migration at full volume

Moves and upgrades

View service

A migration that works on a sample can take days, or fail, on the full data set. We rehearse it at full size.

What we test

Migration run time on full production-sized data
Record counts, totals and data integrity afterwards
Downtime needed, and how long a rollback takes
Performance of the new system with migrated data

When you need it

Before database upgrades, platform moves and system replacements.

The problem it preventsA go-live weekend that runs out of time. See also data & database testing.

[ Volume testing vs load and endurance testing ]

Other tests grow the traffic or the time. Volume testing grows the data.

A system can serve thousands of users on a small database and struggle with a handful on a big one. That’s why volume gets a test of its own. On the right is what a volume finding looks like.

Aspect	Load testing	Endurance testing	Volume testing
The question	Do we meet targets at expected user peak?	Do we stay stable over hours and days?	Do we still perform when the data is big?
What grows	Users and requests	Time	The amount of data
Typical findings	Bottlenecks at peak traffic	Leaks, drift and build-up	Slow queries, overrunning jobs, failing imports and exports
When to run it	Before every major release	Before long runs between releases	Before data growth, big customers and migrations

Sample volume findingFuture-volume run

Data set: Orders table at 40 million rows: two years of projected growth
Journeys: Account order history and the monthly report
Today’s size: Order history 0.4 s, report 6 s
At 40M rows: Order history 9 s, report timed out after 60 s
Root cause: Sort on an unindexed date column; report built in memory
Fix: Composite index added; report streamed in pages
Retest: Order history 0.5 s, report 11 s at 40M rows

Example only. Real reports use your schema, journeys and data sizes.

[ How we work ]

Six steps from data profile to a faster product

Every data size we test comes from your real numbers and growth. Every script, data set and report belongs to you.

Step 1 of 6
Profile your data

How much data you have, how it’s shaped, which tables and files grow fastest, and what you expect next.

You getData profile
Step 2 of 6
Agree sizes and targets

The data sizes to test, from today’s to your future volume, and the targets each journey and job must meet.

You getVolume test plan
Step 3 of 6
Generate the data

Realistic, production-shaped test data at the agreed sizes, created by scripts so no real customer data is needed.

You getData generation scripts
Step 4 of 6
Run journeys and jobs

User journeys, reports, imports and batch jobs run at each data size, with the database and servers monitored.

You getResults per data size
Step 5 of 6
Find what slows down

Query plans, job logs and metrics analysed to show which query, index or job causes each slowdown.

You getSlow query and job report
Step 6 of 6
Fix, retest, plan ahead

Fixes retested at full volume, plus an outlook for when archiving or partitioning will be needed.

You getBefore-and-after reportData growth outlook

Free one-week POCWe run one key report or query at your future data size and show you what changes, so you can judge our work first.
No real customer data neededWe generate production-shaped test data, so personal data stays where it belongs.
NDA before accessWe sign your NDA first and use test accounts and test data by default.

[ Tools ]