Storage Requirements

📦 Storage Requirements

🔍 Overview

The storage required for GermainUX depends primarily on:

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:

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:

Estimate Session Replay separately from other monitoring data.

📅 Retention

GermainUX may retain different data types for different periods:

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:

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:

📈 Estimated Storage

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

👥 CRM Application

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:

The overhead percentage depends on the datastore and its configuration.

💾 Backup and Recovery

Account separately for:

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:

Calculate usable storage and physical storage separately.

🚀 Disk Performance

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

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:

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

✂️ Reduce Storage Consumption

Storage can be reduced by adjusting:

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

📋 Validate the Estimate

Before production rollout:

1. Monitor a representative group of users and applications.

2. Measure actual monitoring units generated per day.

3. Measure average Session Replay volume per user-hour.

4. Test peak and normal activity.

5. Measure datastore compression and indexing overhead.

6. Apply the proposed retention policies.

7. Include replication, backups, and operational free space.

8. Project expected growth.

9. Validate ingestion and query performance.

10. Review the final sizing with Germain Software.

Repeat the sizing exercise when:

For a deployment-specific storage estimate, contact Germain Software.

Contact Germain Software to discuss an on-premise deployment or request assistance.