Storage Requirements

ComponentsEnterprise

Availability2014.1 or later

What drives storage needs

Sizing Example

Worked storage estimate

Production Capacity Planning

Plan for production volume

Validate the Estimate

Test sizing before rollout

Overview

The storage required for GermainUX depends primarily on:

Volume of monitoring data collected
Type and frequency of telemetry
Number of monitored users and applications
Session Replay activity
Raw and aggregated data-retention periods
Datastore technology
Indexing, replication, backup, and operational overhead

The figures on this page provide initial estimates only. Complete a sizing exercise using representative production activity before provisioning storage.

Primary Storage Drivers

Monitoring Volume

The volume of collected data varies according to:

Number of users
User activity level
Number of transactions
Application complexity
Monitoring frequency
Enabled KPIs and collectors

Show all 9

Code-profiling and tracing depth
HTTP request and response collection
Number of monitored application versions and environments

Different applications can generate significantly different amounts of telemetry even when they have the same number of users.

Session Replay

Session Replay can represent the largest part of the storage requirement. Its volume depends on:

Number of recorded users
Length of recorded sessions
User activity level
Application UI complexity
Replay-event collection frequency
Screenshot or thumbnail capture
Replay-retention period
Exclusion and sampling rules

Estimate Session Replay separately from other monitoring data.

Retention

GermainUX may retain different data types for different periods:

Raw monitoring facts
Root-cause analysis data
Aggregated data
Session Replay
Technical traces
Logs and audit records

Longer retention increases storage approximately in proportion to the retained daily volume.

Datastore Technology

Elasticsearch, PostgreSQL, MySQL, Oracle, and Microsoft SQL Server can have different:

Compression ratios
Indexing overhead
Replication requirements
Storage formats
Temporary-space requirements
Backup behavior

Use measurements from the selected datastore whenever possible.

General Sizing Formula

Estimate each data category separately:

Daily data volume × retention period

Then add:

Indexing and datastore overhead
+ replication
+ backups or snapshots
+ temporary processing capacity
+ operational free space
+ expected growth

The final storage requirement is:

Raw and RCA data
+ aggregated data
+ Session Replay
+ traces and other retained telemetry
+ datastore overhead
+ operational capacity

Do not provision only the calculated usable-data volume.

Monitoring-Data Calculation

A simplified raw-data calculation is:

Average unit size
× monitoring units per day
× raw-data retention

Example:

2,048 bytes
× 1,000,000 units/day
× 60 days
≈ 0.11 TB

Aggregated data should be calculated separately using its average daily volume and retention period.

Session Replay Calculation

A simplified Session Replay calculation is:

Average replay size per user-hour
× recorded concurrent users
× recorded hours per user per day
× replay-retention days

Example:

31 MB/user-hour
× 1,500 users
× 8 hours/day
× 7 days
≈ 2.48 TB

This example assumes that all 1,500 users are recorded for eight hours every day. Sampling fewer sessions or using a shorter retention period can substantially reduce the requirement.

Sizing Example

The following example assumes:

Two monitored applications: CRM and ERP
1,500 concurrent users
Eight hours of use per day
1,000,000 monitoring units per day
2,048 bytes per monitoring unit
60 days of raw and RCA data retention

Show all 9

One year of aggregated data retention
Seven days of Session Replay retention
31 MB of replay data per user-hour

Estimated Storage

Data category	Assumption	Estimated storage
Raw and RCA data	1,000,000 units/day at 2,048 bytes for 60 days	0.11 TB
Session Replay	1,500 users × 8 hours/day × 7 days at 31 MB/hour	2.48 TB
Total estimated application data	Excluding additional operational overhead	2.60 TB

The total is rounded. It does not include all datastore indexes, replicas, backups, temporary files, logs, or required free capacity.

Session Replay Volume by Application Activity

The amount of replay data varies by application, activity level, and replay-event frequency.

ERP Application

User activity	30-second interval	2-minute interval	5-minute interval
Extreme	31.00 MB/hour	27.50 MB/hour	26.80 MB/hour
Expected	6.40 MB/hour	2.90 MB/hour	2.20 MB/hour
Idle	4.00 MB/hour	1.20 MB/hour	0.47 MB/hour

CRM Application

User activity	30-second interval	2-minute interval	5-minute interval
Extreme	10.40 MB/hour	7.50 MB/hour	6.90 MB/hour
Expected	8.20 MB/hour	5.30 MB/hour	4.70 MB/hour
Idle	3.90 MB/hour	1.00 MB/hour	0.39 MB/hour

These figures demonstrate why storage should be based on representative application activity rather than user count alone.

Production Capacity Planning

Datastore Overhead

Add capacity for:

Indexes
Replicas
Transaction logs
Datastore metadata
Compaction or merge operations
Temporary queries and aggregations

Show all 9

Reindexing
Data migration
Software upgrades

The overhead percentage depends on the datastore and its configuration.

Backup and Recovery

Account separately for:

Full backups
Incremental backups
Snapshots
Off-site copies
Disaster-recovery replicas
Backup-retention periods
Temporary restore space

Backup storage should not be counted as available production capacity.

High Availability

A replicated datastore may require multiple copies of the same data. For example, the effective infrastructure requirement may be substantially greater than the usable dataset when the architecture includes:

Replica shards
Multiple database nodes
Cross-region replication
Disaster-recovery environments
Staging or upgrade copies

Calculate usable storage and physical storage separately.

Disk Performance

Capacity alone is not sufficient. Production storage must also provide adequate:

Read and write IOPS
Throughput
Latency
Queue depth
Resilience

Use SSD storage for production deployments. Select a storage-performance tier based on measured ingestion, query, replay, and reporting workloads. Storage that is large enough but too slow can cause data-ingestion delays, slow dashboards, and extended maintenance operations.

Free-Space Reserve

Maintain sufficient unused capacity for:

Ingestion spikes
Index merges
Reindexing
Temporary files
Recovery operations
Growth between capacity reviews

Do not allow the datastore to operate continuously near its maximum capacity.

Reduce Storage Consumption

Storage can be reduced by adjusting:

Raw-data retention
Aggregated-data retention
Session Replay retention
Percentage of users or sessions recorded
Replay capture frequency
Thumbnail and screenshot capture

Show all 11

Monitoring intervals
Request or response body collection
Unnecessary KPIs or telemetry
Non-production environment retention
Duplicate data collection

Any reduction should preserve the evidence required for analysis, troubleshooting, compliance, and historical comparison.

Validate the Estimate

Before production rollout:

Monitor a representative group of users and applications

Measure actual monitoring units generated per day

Measure average Session Replay volume per user-hour

Test peak and normal activity

Measure datastore compression and indexing overhead

Apply the proposed retention policies

Include replication, backups, and operational free space

Project expected growth

Validate ingestion and query performance

Review the final sizing with Germain Software

Repeat the sizing exercise when:

A significant application version is introduced
Monitoring scope expands
Session Replay settings change
Retention policies change
A different datastore is adopted
Data volume or user activity increases substantially

For a deployment-specific storage estimate, contact Germain Software. Contact Germain Software to discuss an on-premise deployment or request assistance.

Get Help

Contact GermainUX Support

The GermainUX team helps you get up and running faster, empower your team, turn data into actionable insights, and optimize performance to deliver measurable business outcomes.

Can't find what you need?

Search all GermainUX docs with Ctrl + K, or use the feedback buttons at the bottom of this page to tell us what is missing.

The content of this document is proprietary to GERMAIN SOFTWARE.