two possibilities to split first:

1. data IS on disk but the metrics panel is lagging. railway's volume usage sampling is not real-time — it can lag several hours after a large restore.
2. data isn't actually in the volume — restored into the wrong service / database, or only into WAL that hasn't been checkpointed yet.

quickest disambiguator: SSH into the postgres service (right-click → copy SSH command, needs railway cli locally), then:

du -sh /var/lib/postgresql/data

if that's ~10GB, the data is on the volume and the metrics panel just needs to catch up. you can also confirm postgres itself sees it: psql → select pg_database_size('your_db_name');.

if it's near zero, the restore didn't land where you think — re-verify you connected to the right host (DATABASE_URL vs DATABASE_PUBLIC_URL, correct project/service/environment) when running pg_restore, and re-run.

worth also forcing a flush: psql -c "CHECKPOINT;". that guarantees any in-flight buffers go to disk and can trigger the metrics sampler to update sooner.

Thank you for the fast answer!

du -sh /var/lib/postgresql/data

1.9G /var/lib/postgresql/data

make sense, since we run a Clean Up before we migrated and the we are already using the DB without issues.

and

select pg_database_size('your_db_name');

Returns also reasonable number.

However, the Metrics still shows Zero bytes:

I have executed psql -c "CHECKPOINT;" --> nothing happens in the Metrics yet. I'll wait.

the du 1.9G + pg_database_size both returning real numbers confirms the data is on the volume. metrics panel showing 0 is now on railway's side at the metrics-collection layer, not anything your end can fix from the data direction.

one thing left to try before escalation: redeploy the postgres service from the dashboard (Cmd/Ctrl+K → "Redeploy"). railway's metrics agent runs as a sidecar that initialises on container start — if the first sample after your restore was 0, the agent sometimes gets stuck reporting that until it restarts. a redeploy re-initialises it and the next sample usually picks up the real value within 15-30 min.

if redeploy + 30 min wait still shows 0, it's a stuck metric on railway's side. tag @brody with the project + service IDs and the screenshots — he can manually re-trigger the metrics sampler for your volume.