Summary: Our Postgres service (Postgres + PostGIS, deployed as postgis/postgis image) was found with "no active deployment" and had apparently been down since a Postgres crash-recovery log showed "database system was interrupted; last known up at [date ~3 days prior]." We've since gotten Postgres itself running again, but the database our application uses now has no tables — the schema and all data appear to be gone, even though the server is healthy.

Timeline of what we found and did:

Discovered the service had no active deployment and its volume was unmounted from it.

Found two files at the volume root: .railway-major-upgrade.lock and .railway-postgres-runtime.lock, suggesting Railway's own automated major-version-upgrade process had run on this service.

Redeployed our original image (postgis/postgis:16-3.4) — crashed on startup with: unrecognized configuration parameter "autovacuum_worker_slots" ... configuration file contains errors.

Tried postgis/postgis:17-3.4 — identical crash.

Determined autovacuum_worker_slots is a PostgreSQL 18–only parameter, meaning the on-disk data had been initialized/touched by PG18.

Used railway volume files download/upload to directly comment out that one line in postgresql.conf on the volume.

Redeployed 16 and 17 again — got a clearer error this time: FATAL: database files are incompatible with server. DETAIL: The data directory was initialized by PostgreSQL version 18, which is not compatible with this version 17.0. Confirmed the actual data pages are genuinely PG18 format.

Deployed postgis/postgis:18-3.6 (current PG18 + PostGIS build) — Postgres started successfully, completed a normal WAL crash-recovery ("redo done," "checkpoint complete"), and reported "database system is ready to accept connections."

However: connecting to the database our app uses shows zero tables — no public schema objects at all, just the empty defaults. No other database or schema on the instance contains our data either.

Looking at the raw data directory (/pgdata/base/), there are 4 numbered subdirectories. One of them has a last-modified timestamp matching the last-known-good time Postgres itself reported during recovery, while the others show today's date from our recovery attempts — possibly leftover/orphaned data from before whatever upgrade process ran. We stopped short of touching raw files further to avoid complicating any recovery.

What we're hoping someone can help with:

Whether the 16→18 major-version upgrade that appears to have run on this service completed correctly, or failed partway through.

Whether there's a recoverable pre-upgrade data directory, snapshot, or internal backup from before the outage, even though the dashboard's Backups tab shows empty for us.

Whether anyone else has hit .railway-major-upgrade.lock leaving a service in this state, and how they resolved it.

Happy to provide more diagnostic detail as needed.