A/B Testing Database Storage Calculator
Estimate the database storage needed for A/B test visitor assignments and event data based on traffic, experiment duration, data volume and replication.
Overview
Use this A/B testing database storage calculator to estimate capacity for experiment visitor assignments and event tracking. Enter your expected traffic, test length, events per visitor, average record sizes, database overhead and replication level to estimate the storage footprint.
How it works
The calculator estimates total experiment visitors by multiplying daily visitors by experiment duration. It then estimates event records by multiplying those visitors by the average tracked events per visitor. Event and assignment record sizes are added together, converted to gigabytes, increased by the chosen overhead allowance, and multiplied by the replication factor. The number of variants is shown as planning context because each visitor normally receives one assignment, rather than one assignment for every variant.
How to use this calculator
- 1Enter the average number of visitors expected each day.
- 2Set the number of days your experiment will run.
- 3Add the average number of tracked events generated by each visitor.
- 4Estimate the stored size of your event and assignment records.
- 5Allow for database overhead and select the number of replica copies.
- 6Review the estimated total storage and raw data volume.
Example Calculation
Average daily visitors
100000
Experiment duration
30
Number of variants
2
Tracked events per visitor
5
Average event record size
0.75
Visitor assignment record size
0.2
Database storage overhead
25%
Replication factor
2
Estimated database storage
28.25 GB
With 100,000 daily visitors over 30 days, five events per visitor, 25% overhead and two copies, the estimate is about 28.25 GB across replicas for roughly 15 million event records.
Frequently asked questions
What data does an A/B testing database usually store?
It commonly stores visitor or user assignments, experiment exposure records, conversion and engagement events, timestamps, variant identifiers and relevant event properties.
Why does the number of variants not multiply storage by itself?
A visitor is normally assigned to one variant in a single experiment, so one assignment record is stored per visitor. More variants can affect record properties or concurrent experiments, but do not automatically create one assignment for every variant.
What should I use for average event record size?
Use a sample from your database or event pipeline where possible. Include identifiers, timestamps, event names, variant data and custom properties that are retained with each event.
Why include database overhead?
Raw record payloads do not account for indexes, metadata, storage-engine structures, fragmentation and operational headroom. The overhead setting provides a practical capacity buffer.
Does this estimate include backups and data warehouse storage?
No. The result estimates database storage for experiment records and replicas. Backups, point-in-time recovery, data warehouse copies, logs and analytics exports should be planned separately.
How can I reduce A/B test storage requirements?
You can retain fewer raw events, limit unnecessary event properties, aggregate older data, apply suitable compression, expire old experiments and avoid indexing fields that are rarely queried.
Explore Related Calculators
Assumptions and warnings
Assumptions
- Each daily visitor is treated as a new visitor assignment for capacity planning.
- Every visitor generates the selected average number of tracked events.
- Average record sizes include the stored identifiers and properties needed for each record.
- The overhead percentage covers estimated indexes, metadata, fragmentation and operational headroom.
- The replication factor represents complete copies of the experiment data, including the primary database copy.
- Results are capacity estimates and actual storage use depends on database design, compression and retention settings.
Warnings
- This calculator provides an infrastructure planning estimate only; measure actual record sizes and database overhead before committing production capacity.
- Data retention, backups, analytics exports and logs can require storage beyond the estimate shown.