Use a dataset to simulate virtual users

When you configure a performance test, each virtual user (VU) executes the selected requests in a repeating loop. By default, every virtual user sends requests with the same data. You can use a dataset to give each virtual user its own row of data, so each one sends requests with unique values such as logins, tokens, or payloads.

Unlike a data file, which is a static CSV or JSON file uploaded per run, a dataset is a data source shared across your collections, mocks, and runs. You define the data once and shape it with views, so the same dataset can power your collection runs, mock servers, and performance tests without duplication. Datasets can be backed by local files or live external databases.

A dataset has no file size limit, so you can drive a test from a larger set of rows. A larger dataset doesn’t slow down tests because data is fetched during preparation of the performance run and doesn’t fall into the critical path of sending requests. This is why no latency is added to your requests.

To generate more load than a single machine can produce, run the performance test in the Postman Cloud, where Postman distributes the test across its managed infrastructure and each virtual user still draws its own row from the dataset.

Access data in scripts

During the performance test, each virtual user’s assigned row is available in pre-request and post-response scripts using pm.iterationData. The keys you pass to pm.iterationData.get() correspond to the fields exposed by the view you selected. For example, if your view includes a token field, each virtual user can authenticate with a unique token:

const token = pm.iterationData.get('token');
pm.request.headers.upsert({
    key: 'Authorization',
    value: `Bearer ${token}`
});

Learn more about using iteration data variables in scripts.

Run a performance test with a dataset

Select a dataset and view to drive your performance test. Each virtual user is handed data from the dataset according to the iteration strategy you choose.

Before you begin, create a dataset with the data you want to use.

To run a performance test with a dataset, do the following:

1. Configure a performance test, specifying the number of Virtual users, the Test duration, and a Load profile.

2. Under Iteration data, select the Datasets tab.

3. Select a dataset and a view. The view controls which rows and columns are available to virtual users during the test.

4. Under Iteration Strategies, select how rows are mapped to virtual users. Learn more about iteration strategies.

5. Click Run to start the performance test.

Iteration strategies

Iteration strategies control how the rows from your selected view are assigned to virtual users during the run. They reuse the rows you have to cover every virtual user and don’t generate new rows, so rows repeat when there are more virtual users than rows. The strategies differ in whether a virtual user keeps the same row for the whole test or takes a new one each time it runs the requests. For example, if your view returns 500 rows and you run 1,000 virtual users:

• Round-robin (default) — Rows are handed out in the order requests are made, not per virtual user: the first request uses row 1, the next uses row 2, and after the last row the rotation wraps back to row 1 and keeps cycling. Because the rotation is shared, a single virtual user doesn’t step through the rows in order. It takes whatever row is next each time it sends a request. With 500 rows, requests cycle through rows 1 to 500 and repeat for the rest of the test, giving even coverage across all rows.

• Fixed — Each virtual user is pinned to a single row and uses it for the entire test, so its data never changes. VU N uses row N, wrapping past the last row, so with 500 rows, virtual users 501 to 1,000 reuse rows 1 to 500, and each row is used by two virtual users. Use this when a virtual user must represent one identity throughout the test, such as load-testing real auth or per-user flows.

• Random — Each time a virtual user runs the requests, it takes a uniformly random row, so its data changes on each loop but without any order. With 500 rows, some rows might be used many times and others might never be used, so there’s no coverage or uniqueness guarantee. Use this to simulate unpredictable, mixed traffic.