The dashboard metric is the authoritative figure for billing. It tracks ZFS-level allocated blocks, not the logical size of your files, so it will always read higher than df/du inside the container. Volumes use 16 KB storage blocks while the container's ext4 filesystem operates in 4 KB blocks, so a 16 KB block that is only partially freed can never be returned. With scattered small-file workloads (images, attachments, documents) this allocation floor can sit at 2-4x the guest-visible usage permanently. Since your df and du agree at ~1.5 GB, this is purely the block-size mismatch, not leaked file handles or anything else to investigate. Also worth checking: if you have ever resized this volume, an automatic backup snapshot ("Online resize to …") appears in the volume's Backups tab with no expiry, and it pins freed blocks as Backup Usage. Deleting that snapshot is the biggest self-serve lever for reducing the reported figure. In dollar terms the ~2.6 GB gap costs roughly $0.39/month.

I’m currently using 4.15 GB out of a 5 GB volume according to the Railway dashboard, so I was considering increasing the volume size. However, when I checked the actual usage inside the container, both df and du showed that I’m only using around 1.5 GB.

I understand the issue with ZFS block allocation and the block-size difference between ZFS and ext4, and I understand why the allocated size can be larger than the logical size of my files.

What I’m having difficulty understanding is whether it’s reasonable for me to pay for additional storage when I’m approaching the 5 GB allocation limit not because I’ve actually stored close to 5 GB of data, but largely because of overhead from the underlying storage implementation.

If my actual data is only around 1.5 GB, but storage-level overhead causes the volume to approach its 5 GB limit, requiring me to increase the volume size and pay more, I’m not sure this feels like a reasonable way to account for storage usage.

Especially if the 2–4x difference you mentioned is an expected and persistent characteristic for small-file workloads, does this mean that a 5 GB Railway volume may effectively provide significantly less than 5 GB of usable storage for this type of workload?

I’d appreciate your perspective on this.

To correct my earlier message, backup snapshots do not contribute to the volume usage metric, so deleting them would not reduce the figure you see. For scattered small-file workloads, the 16 KB block floor does mean a 5 GB volume holds meaningfully less than 5 GB of logical data, and that gap is persistent. Provisioned volume size is not billed, only measured usage, so the ~4.15 GB figure is what you pay for regardless of the volume's total capacity. The one self-serve lever that resets the allocation accounting is migrating your data to a fresh volume (create a new volume, copy the files over, then delete the old one), which starts the block accounting from zero.