Azure PostgreSQL Flexible Server: Backup Storage Growing to TBs Despite Low DB Size

Hi,

We have completed a detailed investigation into the backup storage growth issue on our Azure PostgreSQL Flexible Server and would like to provide concrete findings.

Summary of Issue

• Database size: ~331 GB
• Backup storage usage: ~6–8 TB
• Backup retention: 7 days

Backup storage continues to remain at TB scale despite minimal activity

Investigation Findings

1. No significant database write activity

Azure Metrics (Write IOPS over last 3 days):

Mostly between 1–2 IOPS, with rare spikes up to ~5–6

Long periods of near-idle activity

This indicates the database is effectively idle and not generating significant write load (Please find the attachment)

2. WAL generation is negligible

From pg_stat_wal:

Total WAL generated over ~2–3 days: ~7.5 MB

This is extremely low and does not justify TB-scale backup usage

3. No replication slots present

SELECT * FROM pg_replication_slots;

Result: No rows returned

This rules out WAL retention caused by replication slots.

4. No long-running transactions

SELECT pid, now() - xact_start AS duration, query
FROM pg_stat_activity
WHERE state != 'idle';

No active long-running transactions

5. No data churn (updates/deletes)

From pg_stat_database:

tup_updated and tup_deleted are near zero

Indicates no high-churn workload

6. No autovacuum pressure or dead tuples

From pg_stat_user_tables:

n_dead_tup = 0 across tables

No evidence of vacuum lag or accumulation

Key Observation

There is a clear mismatch:

• WAL generation: ~7.5 MB over multiple days
• Write IOPS: ~1–2 (idle)
• Database activity: minimal
• Backup storage: ~6–8 TB

These metrics do not correlate. Under normal PostgreSQL behavior, such low WAL generation cannot produce TB-scale backup storage.

Conclusion

Based on the above evidence, the backup storage growth and retention at TB scale cannot be attributed to:

• WAL generation
• Database workload
• Replication slots
• Long-running transactions
• Autovacuum or table churn

This strongly suggests a platform-side issue, such as:

• Backup chain not being cleaned up correctly
• WAL retention at the platform layer
• Incorrect backup storage accounting
• Or orphaned backups not being garbage-collected

Request

We request further investigation into:

• Backend backup chain cleanup for this server
• WAL retention behavior at the Azure platform level
• Backup storage accounting accuracy

This issue is currently incurring approximately $15–20 per day in charges, which is not sustainable.

We request urgent investigation and resolution. Additionally, we request compensation/credit adjustment for the excess backup storage charges incurred since March 18th, as this behavior appears to be unrelated to our workload.

Write IOPS log:

Backup storage used log:

Note: Due to the ongoing unexpected backup storage charges, I am planning to terminate this Azure PostgreSQL Flexible Server today to prevent further cost impact. We would appreciate an update as soon as possible today.

Thanks.