A/B Testing Database Storage Formula
Learn how annual A/B testing database storage is estimated from visitor volume, experiment participation, events, record sizes, metadata, and overhead.
This formula estimates the database capacity required to retain one year of A/B test assignments, experiment events, and basic test metadata. It helps teams turn expected experimentation activity into a storage-planning estimate before adding separate backup, replica, or logging capacity.
- 100% Free
- No Sign-Up Required
- Private & Secure
- Mobile Friendly
Estimated Annual Database Storage
Where:
First estimate how many visitors participate across all tests, then calculate storage for their events and assignment records. Add small per-variant metadata storage and increase the total by the selected database overhead percentage.
Variables Explained
| Variable | What It Means | Unit |
|---|---|---|
| monthlyVisitors - Monthly visitors | Average number of unique visitors or users available each month. | visitors |
| testsPerYear - A/B tests per year | Number of experiments expected to collect data during the year. | tests |
| trafficAllocation - Traffic included per test | Percentage of monthly visitors included in a typical experiment. | percent |
| eventsPerParticipant - Events per participant | Average retained tracking events generated by one participant in one test. | events |
| averageEventSizeKb - Average event size | Average stored event payload size before indexes and database overhead. | KB |
| assignmentSizeBytes - Assignment record size | Average size of one experiment assignment or exposure record. | bytes |
| averageVariants - Average variants per test | Average number of variants including the control. | variants |
| storageOverhead - Database storage overhead | Allowance for indexes, row headers, free space, and similar local database overhead. | percent |
| annualEventRecords - Annual event records | Estimated experiment-related event rows retained over the year. | events |
| experimentParticipants - Experiment participant records | Estimated assignment or exposure records across all experiments. | records |
Step-by-Step Calculation
Estimate annual visitors
Multiply the average monthly visitor volume by 12 to estimate the visitors available during the year.
annualVisitors = monthlyVisitors * 12
Estimate experiment participant records
Each visitor included in a test is counted once for that test. A person may therefore contribute records to multiple experiments.
experimentParticipants = annualVisitors * testsPerYear * (trafficAllocation / 100)
Estimate annual event records
Multiply experiment participant records by the average retained events per participant.
annualEventRecords = experimentParticipants * eventsPerParticipant
Calculate event payload storage
Convert event payloads from KB to bytes using 1 KB = 1,024 bytes, then convert bytes to decimal GB.
eventStorageGb = annualEventRecords * averageEventSizeKb * 1024 / 1000000000
Calculate assignment and metadata storage
Add storage for assignment records and an allowance of approximately 50 KB of metadata per test variant.
assignmentStorageGb = experimentParticipants * assignmentSizeBytes / 1000000000; metadataStorageGb = testsPerYear * averageVariants * 51200 / 1000000000
Apply database overhead
Increase raw storage by the overhead allowance to account for indexes, row overhead, and capacity headroom.
annualStorageGb = (eventStorageGb + assignmentStorageGb + metadataStorageGb) * (1 + storageOverhead / 100)
Worked example: 100,000 monthly visitors and 12 tests
Annual visitors
100,000 × 12
1,200,000 visitors
Experiment participant records
1,200,000 × 12 × 0.50
7,200,000 records
Annual event records
7,200,000 × 20
144,000,000 events
Event payload storage
144,000,000 × 1 × 1,024 ÷ 1,000,000,000
147.456 GB
Assignment and metadata storage
(7,200,000 × 200 ÷ 1,000,000,000) + (12 × 3 × 51,200 ÷ 1,000,000,000)
1.442 GB
Storage after overhead
(147.456 + 1.442) × 1.40
208.5 GB
Final Result
Estimated annual database storage: approximately 208.5 GB, or 0.21 TB.
Assumptions
- ✓Monthly visitor volume remains broadly consistent for all 12 months.
- ✓Each included visitor produces one assignment or exposure record for every test they enter.
- ✓The events-per-participant input represents only events retained for experiment analysis.
- ✓The overhead percentage covers local database overhead and headroom, not full backup copies.
- ✓Storage uses decimal GB and TB, where 1 TB equals 1,000 GB.
Limitations
- !Actual event sizes can differ because schemas, optional properties, serialization, and compression vary.
- !Experiment overlap, duration, and changing traffic allocation can make actual participant counts differ from the estimate.
- !Partitioning, indexes, replication topology, and database engine behavior may materially change physical storage use.
- !Backups, replicas, transaction logs, exports, and non-experiment analytics data are not separately calculated.
Common Mistakes to Avoid
Entering total website events rather than experiment-related events retained per participant.
Treating 50% traffic allocation as 50 instead of using the calculator's percentage input.
Excluding the control when entering the average number of variants.
Using compressed transfer size instead of the typical stored event payload size.
Assuming the overhead allowance also includes separate backup and replica copies.
Related Formulas
Frequently Asked Questions
How is A/B testing database storage calculated?
The calculation estimates annual visitors, participant records across experiments, retained event records, event payload storage, assignment storage, and metadata. It then applies the selected overhead percentage.
Why are visitors multiplied by the number of tests?
The estimate treats participation in each test as a separate assignment opportunity. A visitor who enters several experiments can create records for each experiment.
Does the number of variants greatly affect storage?
In this calculation, variants affect only the small metadata allowance. Participant and event volume usually have a much larger effect on total storage.
Why does the formula use 1,024 bytes per KB?
Event payload input is converted using 1 KB = 1,024 bytes, while the final GB result is expressed as decimal GB using 1,000,000,000 bytes.
What overhead percentage should be used for database storage?
Use an allowance that reflects your expected indexes, row overhead, free space, and operational headroom. The appropriate percentage depends on the database design and workload.
Does the formula include data retention or deletion?
No. It estimates one year's retained data. If data is deleted, aggregated, or archived sooner, required live storage may be lower.
Ready to calculate your result?
Use the calculator to get instant results with your own inputs.