Hi Railway team,

Our production PostgreSQL instance has had intermittent storage stalls for roughly three weeks, causing 20–130 second write freezes on a live e-commerce store. Today it also failed to mount after the restart triggered by Railway's built-in "Enable pg_stat_statements" toggle, causing a production outage until we manually restarted a second time.

On our end, we've investigated the application, business logic, and runtime and found nothing that accounts for this. Our evidence points to an infrastructure-level storage issue rather than our workload, but we'd appreciate you validating that, or pointing us in another direction if we've missed something.

Environment

• Production Postgres (PostgreSQL 16.8), volume vol_ycdz1lj34euudto1 -> affected
• Development Postgres (same version/config), volume vol_ea4x1k2wcz9rn3s0 -> healthy control
• The production DB is only ~110 MB with typically 5-15 connections, which makes the checkpoint times below highly abnormal.
• Project: tactic-teamstores
• Region: Netherlands

**Evidence 1 **: checkpoint fsync stalls (from Postgres' own logs). PostgreSQL regularly spends 55–274 seconds flushing only 96–184 KB during checkpoints; healthy storage typically completes these fsync operations in milliseconds. Recurring from at least June 16 through July 5, across multiple deploys and restarts:

2026-06-28 16:05 UTC  ~176 KB  sync=87.9s   total=124.4s  longest fsync=86.8s

2026-07-01 17:07 UTC  ~120 KB  sync=113.9s  total=120.7s  longest fsync=112.2s

2026-07-02 09:18 UTC  ~184 KB  sync=133.3s  total=143.0s  longest fsync=132.7s

2026-07-02 20:17 UTC   ~96 KB  write=274.4s total=410.4s

2026-06-19 09:05 UTC  ~112 KB  sync=55.0s   longest fsync=53.6s

The WAL generated per checkpoint is tiny (a few KB), so this is not write load. During these events, read queries respond normally while any transaction requiring a WAL fsync (any COMMIT) blocks for 20-130 seconds, a recognizable storage-layer symptom.

Evidence 2: failed to mount after restart (today). We enabled pg_stat_statements via Railway's built-in dashboard toggle, which triggered the expected PostgreSQL restart. After the restart, the service logged only Mounting volume on: …/vol_ycdz1lj34euudto1 and made no further progress, PostgreSQL never started, and the database refused connections until a second manual restart.

Evidence 3: identical dev DB, same action, healthy. The development DB (vol_ea4x1k2wcz9rn3s0) had the exact same toggle + restart at ~05:14 UTC and behaved normally. Same action, same config, only the production volume/host misbehaves:

Production (vol_ycdz1lj34euudto1): failed to mount, PostgreSQL never started, outage until a 2nd manual restart.

Development (vol_ea4x1k2wcz9rn3s0): restarted in ~1 second, WAL replay 0.02 s, checkpoint sync=0.003s.

Current status: Since the second restart, the DB is responsive and we haven't seen a stall yet. Given the three-week history across many restarts, we suspect a temporary lull rather than a fix. If today's restart resulted in the service being scheduled onto different infrastructure, that could explain the improvement, could you confirm whether that occurred?

In the window since enabling pg_stat_statements (1 hour ago), the slowest statement is ~100 ms and no application query exceeds ~72 ms, so routine slow queries aren't the cause. This window hasn't captured a stall event yet, so it complements the checkpoint evidence above rather than proving it; we're watching COMMIT latency there and expect it to spike during the next stall.

Requests

1. Can you determine whether this is infrastructure-related, the I/O health/throttling of volume vol_ycdz1lj34euudto1 and its host?
2. Did today's restart move the service onto a different host/node?
3. If so, can the database be kept on healthy storage permanently, and if not, can you migrate it there?
4. What production storage tier do you recommend for consistent write/fsync latency?

Happy to share full logs or run any diagnostics.