The volume usage figure we show is the storage layer's allocated blocks for the volume, not the size of the files inside it, so it can sit well above what du and df report. We currently read about 470 MB on that volume while your filesystem shows about 15 MB, and since df and du agree with each other, this is not deleted files being held open by your process.

Two things produce the gap. Blocks freed inside ext4 are only handed back once they are discarded, and the volume allocates in 16 KB blocks while ext4 frees in 4 KB blocks, so a partially freed 16 KB block stays allocated. Workloads that rewrite small pieces of a file often, like frequent SQLite updates, are the typical case. The figure settles somewhere above df, not at it, and backups play no part in it.

Your data is intact and nothing is wrong inside the container. Running fstrim from inside the container returns "Operation not permitted", which is expected, and there is no manual reclaim on our side. Volume billing does follow this figure, at $0.15 per GB-month, so the excess is worth roughly $0.07 per month at current levels.

Thank you for the explanation.

I understand that the discrepancy may be caused by storage-layer block allocation and frequent SQLite updates.

However, my main concern remains unresolved:

If Railway reports 470 MB used out of a 500 MB volume, will database writes fail when the reported usage reaches 500 MB, even though df shows approximately 409 MB available?

Could a human support engineer confirm how the 500 MB limit is enforced and whether there is a safe, non-destructive way to prevent the application from becoming unable to write?

I do not want to modify or delete production data without understanding the risks.

Thank you.

The 470 MB figure counts the blocks the storage layer has allocated for the volume, not the size of the files inside it, which is why it sits well above what df and du report. With frequent small SQLite writes, it settles above the df figure rather than matching it, and we don't run a manual reclaim to bring it down.

Your data is intact, nothing has been changed on the volume, and none of this requires you to delete or modify production data.

Thank you for the explanation.

I understand now why the allocated volume usage is much higher than the actual file sizes.

However, my main concern is still unresolved:

If the allocated volume usage reaches the 500 MB limit, will my application stop being able to write data, even if df -h and du show plenty of free space?

I've already reduced unnecessary SQLite writes in my application, but the allocated usage is still around 475 MB.

Could you please clarify whether reaching this limit will affect the application's ability to write new data?

I would also appreciate knowing whether there is a safe way to address the existing allocation without deleting or replacing production data.

Thank you!

The 500 MB is the size of the disk your ext4 filesystem sits on, and the usage figure counts which blocks of that same disk have ever been written and not yet handed back. Because it measures the same 500 MB disk, it tops out near capacity rather than going past it. Whether a write succeeds depends on free space inside the filesystem, which is the roughly 409 MB that df reports. Overwriting or reusing blocks that are already counted needs no new space.

On reclaiming the existing allocation, there is no action for you to take and no safe step that requires touching your data. Freed blocks are handed back automatically through the discard mount over time, but the figure settles above what df shows rather than matching it. Running fstrim inside the container is not permitted, we don't run a manual reclaim, and replacing or recreating the volume would not change this. Your data has not been modified.