A/B Testing Database Storage Formula
Learn how to estimate monthly A/B testing database storage from experiment traffic, records, record size, replication, and overhead.
This formula estimates the database storage generated by A/B testing activity in one month. It helps translate experiment traffic and tracking design into a capacity estimate that includes replicated copies and database index or metadata overhead.
- 100% Free
- No Sign-Up Required
- Private & Secure
- Mobile Friendly
Monthly A/B Testing Database Storage
Where:
Find the visitors included in experiments, multiply by the records stored for each visitor and the average record size, then allow for database replicas and overhead. Divide the KB total by 1,048,576 to express the result in GB.
Variables Explained
| Variable | What It Means | Unit |
|---|---|---|
| monthlyVisitors - Monthly visitors | Total visitors or users tracked during one month. | visitors |
| experimentTrafficPercent - Traffic included in experiments | Percentage of monthly visitors enrolled in active A/B tests. | percent |
| eventsPerVisitor - Tracked records per experiment visitor | Average number of stored experiment-related records generated by each enrolled visitor. | records |
| averageRecordSizeKb - Average record size | Average stored size of one record before replication and index or metadata overhead. | KB |
| replicationFactor - Database replication factor | Number of stored copies, including the primary copy and replicas. | copies |
| indexOverheadPercent - Index and metadata overhead | Additional storage allowance for indexes, metadata, and database-engine structures. | percent |
| retentionMonths - Data retention period | Number of months that generated A/B testing data remains stored. | months |
Step-by-Step Calculation
Estimate experiment visitors
Calculate how many monthly visitors are included in experiments.
experimentVisitors=monthlyVisitors*(experimentTrafficPercent/100)
Calculate monthly tracked records
Multiply experiment visitors by the average number of records stored per participant.
monthlyRecords=experimentVisitors*eventsPerVisitor
Calculate raw storage
Multiply record count by the average record size to get storage before database overhead.
rawStorageKb=monthlyRecords*averageRecordSizeKb
Add replication and overhead
Allow for all stored copies and the additional space used by indexes, metadata, and similar structures.
storageWithOverheadKb=rawStorageKb*replicationFactor*(1+indexOverheadPercent/100)
Convert storage to GB
Convert KB to binary GB, where 1 GB equals 1,048,576 KB.
monthlyStorageGb=storageWithOverheadKb/1048576
Estimate retained storage
Multiply monthly storage generation by the retention period when monthly cohorts are kept at a steady rate.
retainedStorageGb=monthlyStorageGb*retentionMonths
Worked example: 100,000 visitors and 50% experiment traffic
Experiment visitors
100,000 × (50 ÷ 100)
50,000 visitors
Monthly tracked records
50,000 × 10
500,000 records
Raw monthly storage
500,000 × 0.5 KB
250,000 KB
Storage after replication and overhead
250,000 × 3 × (1 + 30 ÷ 100)
975,000 KB
Monthly storage in GB
975,000 ÷ 1,048,576
0.93 GB
Storage for 12 months
0.9298 × 12
11.16 GB
Final Result
Estimated monthly A/B testing database storage: 0.93 GB. Estimated storage after 12 months of retention: 11.16 GB.
Assumptions
- ✓Every visitor included in experiments generates the same average number of stored records.
- ✓The average record size is measured before adding replicas, indexes, metadata, and related storage structures.
- ✓Monthly traffic, experiment participation, event volume, and record size remain stable over the retention period.
- ✓Retained data is kept online without compression, archival, deletion, or aggregation.
- ✓Storage uses binary units: 1 GB equals 1,048,576 KB.
Limitations
- !Actual storage can differ because schemas, field types, row formats, and database engines use space differently.
- !Index size may not grow in direct proportion to raw event data, especially with several indexes or high-cardinality fields.
- !This estimate does not include backups, snapshots, exports, analytics warehouses, logs, or disaster-recovery storage.
- !Traffic spikes, bot traffic, new experiments, and additional tracking fields can raise storage above the estimate.
- !Compression, deduplication, partitioning, and archival policies may reduce online storage requirements.
Common Mistakes to Avoid
Entering all site visitors as experiment visitors instead of applying the percentage of traffic enrolled in tests.
Counting only conversion events while omitting assignments, exposures, feature evaluations, and participant attributes stored as records.
Using payload size rather than the measured stored record size when records have database encoding or fixed-field overhead.
Setting the replication factor to the number of replica nodes but forgetting that the primary copy is also included.
Treating index overhead as a backup allowance; backups and snapshots need separate capacity planning.
Using decimal GB conversions when the calculator uses 1,048,576 KB per GB.
Related Formulas
Frequently Asked Questions
How is monthly A/B testing database storage calculated?
The calculation multiplies experiment visitors by records per visitor and average record size, then multiplies by replication and index or metadata overhead before converting KB to GB.
What records should be included in records per experiment visitor?
Include assignments, exposures, conversions, feature-flag evaluations, metrics, and other participant-level records stored in the database.
Does the replication factor include the primary database copy?
Yes. A replication factor of 3 means three stored copies in total, including the primary copy.
Why is index and metadata overhead added after raw storage?
Raw storage represents record data alone. Indexes, metadata, and internal database structures generally require additional space beyond that data.
How do I calculate storage for a retention period?
Multiply the estimated monthly storage by the number of months retained, provided monthly activity and storage behavior stay similar.
Does a higher number of test variants always require more storage?
Not by itself. Storage rises when more variants lead to more stored events, assignments, attributes, or analysis records per participant.
Ready to calculate your result?
Use the calculator to get instant results with your own inputs.