We need Railway's written architecture guidance for a production PostgreSQL service that uses a legacy volume mount at /var/lib/postgresql. Railway's current standard/PITR-compatible layout uses /var/lib/postgresql/data. We will not expose PostgreSQL publicly, change credentials, replace the source volume, run an in-place destructive experiment, or purchase/change a plan without separate approval.

Please confirm the safest supported and reversible path:

OPTION A — provider-managed clone-first migration

Can Railway Support/Admin clone or migrate the existing service/volume to the standard layout while retaining the original volume unchanged for rollback? Please provide the supported runbook, backup prerequisite, data-consistency mechanism, source impact/restarts, exact downtime, networking/credential impact, rollback boundary/steps, cost or plan requirement, and who performs each step.

OPTION B — new private standard PostgreSQL service

What supported private mechanism can migrate a legacy standalone PostgreSQL database into a new standard Railway PostgreSQL service without public exposure? Please cover consistent initial copy; logical replication if supported; source restart requirements; final write freeze; zero-lag verification; sequences, extensions, and roles; Railway reference-based private credentials; rollback boundary/order; downtime; cost/plan requirement; and Support/Admin involvement.

TARGET RECOVERY

After migration, please confirm whether the standard target supports PITR, a completed first base backup, healthy WAL archiving, and restore to a new private sibling service (never replacing the source). We need a drill that measures achieved RPO and end-to-end RTO, with acceptance targets RPO <= 15 minutes and RTO <= 2 hours.

The application candidate adds no database migration. Production remains unchanged while we gather this guidance.