a month ago
My Postgres service ran out of disk on a 500MB volume. I resized it to 5GB through the dashboard, and the UI confirmed the new size, but the actual block device never expanded.
I confirmed this by running df -h inside the container with a custom start command. The device /dev/zd12688 still showed 434MB at 100% capacity, even after the resize:
/dev/zd12688 434M 424M 204K 100% /var/lib/postgresql/data
The volume metrics page also showed 5GB max size with near-zero usage, which was misleading — it wasn't reflecting the actual mounted device.
Additionally, the volume was consistently mounting after Postgres had already started, causing a race condition where Postgres would attempt WAL recovery on the full disk and crash before the volume was available.
This left me in an unrecoverable crash loop. I was unable to connect to the database, unable to free space, and ultimately had to delete the service and lose all data.
1 Replies
Status changed to Awaiting Railway Response Railway • about 1 month ago
a month ago
We're sorry about the data loss. This is a known issue where a volume resize confirmed in the dashboard does not always propagate to the underlying filesystem, leaving the block device at its original size. Our infrastructure team has been investigating this. For future protection, we recommend enabling volume backups which support daily, weekly, and monthly schedules and allow point-in-time restores.
Status changed to Awaiting User Response Railway • about 1 month ago
a month ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • about 1 month ago