> ## Documentation Index > Fetch the complete documentation index at: https://docs.germainux.com/llms.txt > Use this file to discover all available pages before exploring further. # Storage Requirements > Estimate the storage GermainUX needs based on data volume, retention and the features you use. Components [`Enterprise`](https://docs.germainux.com/main/deployment-on-premise) Availability 2014.1 or later > [card] [Storage Requirements](#overview) > > What drives storage needs > [card] [Sizing Example](#sizing-example) > > Worked storage estimate > [card] [Production Capacity Planning](#production-capacity-planning) > > Plan for production volume > [card] [Validate the Estimate](#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 > [accordion] 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: ```text theme={null} Daily data volume × retention period ``` Then add: ```text theme={null} Indexing and datastore overhead + replication + backups or snapshots + temporary processing capacity + operational free space + expected growth ``` The final storage requirement is: ```text theme={null} 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: ```text theme={null} Average unit size × monitoring units per day × raw-data retention ``` Example: ```text theme={null} 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: ```text theme={null} Average replay size per user-hour × recorded concurrent users × recorded hours per user per day × replay-retention days ``` Example: ```text theme={null} 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 > [accordion] 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 > [accordion] 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 > [accordion] 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: **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: * 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](https://docs.germainux.com/main/support.md) Software to discuss an on-premise deployment or request assistance. ## Get Help > [card] [Contact GermainUX Support](https://docs.germainux.com/main/support.md) > > 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. > [card] 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.