Volume Usage increases despite minimal filesystem growth
gustjr4519
HOBBYOP

a day ago

Hello Railway Team,

I'm experiencing a persistent discrepancy between Railway's reported Volume Usage and the actual filesystem usage inside my service.

Environment

  • Plan: Hobby
  • Application: Python Discord bot using SQLite
  • Persistent volume: discord-recruit-bot-volume
  • Mount path: /data

Measurements

September 30, 2026:

  • Railway Volume Usage: 1.28 GB
  • Filesystem usage (df): 980 KB
  • SQLite database: 632 KB
  • Cumulative process disk writes: 147.13 MB

October 27, 2026:

  • Railway Volume Usage: 1.40 GB
  • Filesystem usage (df): approximately 1.18 MB
  • SQLite database: 864 KB
  • Cumulative process disk writes: 1.34 GB
  • SQLite WAL/SHM: Not present
  • SQLite freelist pages: 0

Over approximately 27 days, Railway's reported Volume Usage increased by about 120 MB, while actual filesystem usage increased by only around 0.2 MB.

I understand that SQLite performs repeated writes to existing database pages, and that cumulative disk writes are not equivalent to allocated storage.

However, I would like to understand why Railway's reported volume usage continues to increase significantly while df, du, and the actual database size remain nearly unchanged.

Could you please clarify:

  1. What exactly is included in Railway's Volume Usage metric?
  2. Can repeated SQLite writes to existing database pages increase the reported Volume Usage without corresponding growth in df or du?
  3. Is this discrepancy expected, or could it indicate an issue with storage allocation or usage accounting?
  4. Is there a recommended way to diagnose the difference?

I have attached screenshots showing the 30-day Volume Usage graph and filesystem diagnostics.

Thank you for your help.

Note: The diagnostic screenshots are displayed in Korean because they were generated by my bot's custom monitoring command. The relevant measurements have been translated into English in the report above.

The screenshots are provided as supporting evidence of the actual filesystem usage and cumulative process disk writes.

ChatGPT 이미지 2026년 10월 27일 오후 04_47_53.png

ChatGPT 이미지 2026년 10월 27일 오후 04_48_00.png

ChatGPT 이미지 2026년 10월 27일 오후 04_48_06.png

Awaiting User Response

1 Replies

Railway
BOT

a day ago

The Volume Usage metric shows the storage blocks allocated to the volume on our storage layer. It does not show the size of the files your filesystem can see. When data is rewritten or deleted inside the container, the freed space only goes back to the volume when those blocks are discarded. Our storage also allocates in 16 KB blocks, while ext4 frees space in 4 KB blocks, so a block that is only partly freed stays allocated.

So yes, frequent rewrites of existing SQLite pages can raise the reported usage while df and du stay flat. This is expected accounting, not a storage fault, and your data is fine. The metric will settle above what df shows rather than match it.

Your df and du figures agree with each other, which rules out deleted files that a process is still holding open. Running fstrim inside the container will fail with "Operation not permitted", which is expected. There is nothing you need to change.

Volume billing is based on this metric, at $0.15/GB-month, so 1.4 GB works out to roughly $0.21 per month.


Status changed to Awaiting User Response Railway • 1 day ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...