Hi Railway team,

I'm seeing intermittent but severe performance degradation on my Postgres service and the evidence points to disk I/O on your side rather than my workload, so I'd like you to check the underlying volume metrics for my service.

The symptom: the database runs fine most of the time, then occasionally becomes extremely slow for a period before recovering on its own. After enabling wait event monitoring I caught it in the act. A simple COMMIT was stuck for almost 12 seconds with wait_event_type = IO and wait_event = WALSync, meaning the backend was waiting on fsync of the write-ahead log. A healthy fsync should take single-digit milliseconds, so this indicates the disk was either throttled or saturated at that moment.

My write volume is modest and the episodes don't correlate with any spike in my own query load, which is why I suspect IOPS throttling or burst credit exhaustion on the volume, or contention from a noisy neighbor.

Could you please check with me?

Happy to provide more diagnostics from pg_stat_activity or pg_stat_wal if useful.

Thanks,

Davide