A/B Testing Database Storage Calculator FAQ

It estimates the database storage generated in one month by experiment-related records, then estimates storage held for a chosen retention period.

No. The result is a storage-capacity estimate in GB. Database pricing can also depend on compute, requests, backups, regions, and provider-specific charges.

Yes. Use the records and record size that reflect the data stored by the implementation, whether assignments and events originate on the server, client, or both.

No. It estimates the selected database storage only. Warehouses, object storage, exports, and BI extracts should be estimated separately.

An experiment visitor is a tracked visitor or user included in at least one active A/B test during the month.

Count every database record created for an experiment participant, such as assignments, exposures, conversions, feature evaluations, metrics, and stored attributes.

Use measured stored record sizes from representative production data when available. Otherwise, make a documented estimate based on your schema and revise it after measurement.

Include records that your system stores. If duplicates are retained before deduplication or reconciliation, they use storage and should be reflected in the record estimate.

Increase records per visitor if a participant receives separate assignments, exposures, metrics, or attributes for multiple experiments.

It is the total number of stored copies of data, including the primary copy. For example, a factor of 3 represents three copies.

It represents additional capacity used by indexes, metadata, internal structures, and similar database storage costs beyond raw record data.

Usually no. Replication describes database copies used by the deployed system, while backups, snapshots, and disaster-recovery copies commonly need separate planning.

The calculator multiplies estimated monthly storage by the number of months retained. This assumes consistent monthly data generation and no early deletion or compression.

No. It reduces the accumulated retained storage, but the new data generated each month remains the same unless tracking volume or data design changes.

It is a planning estimate. Accuracy improves when inputs are based on production measurements of event rates, stored row sizes, replication, and index usage.

Additional indexes, schema changes, provider allocation behavior, logs, temporary files, growth spikes, and backups can increase total capacity needs.

Yes. Compression may lower stored data size, but its effect depends on the database engine, data format, indexes, and how repetitive the records are.

Capacity plans commonly allow room for normal growth, traffic peaks, new tracking fields, migrations, and operational activity. The appropriate amount depends on the system.

Calculate each month using its expected traffic and tracking inputs, then add the retained monthly cohorts rather than assuming a single constant monthly value.

Yes. Run one estimate for each schema using its own records per visitor, average record size, overhead, and retention assumptions.

Yes. Increase records per visitor, record size, or both according to how the new metric is stored, then compare the revised estimate.

No. The calculation assumes retained data remains in the same storage tier. Archive tiers and their compression or replication policies require a separate estimate.