Database disk usage in Mendix Cloud is higher than logical size reported by a database monitoring tool

Issue

A discrepancy is observed between the database storage size reported by a third-party database monitoring tool and the physical disk usage shown in Mendix Portal metrics for applications hosted in Mendix Cloud. The database monitoring tool reports a smaller value based on logical table and index size, while Mendix Portal shows higher physical disk consumption.

Environment

Applications hosted in Mendix Cloud

Cause

The discrepancy occurs because the two measurements represent different types of storage usage and are not expected to match directly:

• Database monitoring tool (logical view): Reports the size of active table data and indexes based on PostgreSQL system catalogs. This value does not include physical storage overhead.
• Mendix Portal metrics (physical view): Reports total physical disk consumption on the underlying PostgreSQL infrastructure, including components that are not visible in logical size summaries.

Physical disk usage can be higher than logical data size because PostgreSQL also stores and retains additional data structures such as:

• Dead tuples (PostgreSQL bloat): When rows are updated or deleted, PostgreSQL keeps old row versions until that space is reclaimed or reused. This can contribute significantly to physical disk usage.
• Write-Ahead Log (WAL) storage: WAL segments are retained for crash recovery and point-in-time recovery (PITR). Environments with higher write activity can retain more WAL data.
• Index and TOAST overhead: Index pages and storage for large attributes add physical storage beyond the live row payload.
• Internal PostgreSQL structures: Free space maps, visibility maps, pg_xact, pg_multixact, temporary files, and system catalogs also consume disk space.

There is no fixed ratio between logical data size and physical disk usage. The difference depends on workload, auto vacuum effectiveness, WAL retention, table update and delete patterns, and historical database activity.

Solution/Workaround

Use the physical database disk usage shown in Mendix Portal as the reference for capacity planning and out-of-space risk assessment. The database monitoring tool remains useful for understanding logical data volume, but it does not represent the total physical disk footprint. The following guidance applies:

1. Use Mendix Portal physical storage metrics for capacity planning. This metric reflects actual disk consumption on the underlying infrastructure and is the most relevant value when assessing scaling needs.
2. Expect variation between logical and physical size. The difference depends on workload characteristics, update and delete frequency, auto vacuum behavior, WAL retention, and historical bulk operations.
3. Option A: Run pg_repack to reclaim bloated space online on environments that use the new backup service (NBS). This option can reclaim physical space caused by database bloat without requiring full downtime. Feasibility depends on available free space and the size of the largest table.
4. Option B: Use backup and restore on environments that use the old backup service. On the old backup service, a backup and restore procedure can reduce physical storage. This approach does not reduce physical disk size on environments that use the new backup service (NBS), because snapshot-based backups preserve database bloat. 
5. Request a deeper analysis when needed. If an environment-specific breakdown of WAL usage, bloat indicators, TOAST overhead, and related storage components is required, Mendix Expert Services can provide additional analysis.

Additional information

Mendix documentation:

• Reducing database size
• Restore a backup