17 days ago
After the recent crash caused by GCP blocking Railway’s account last week, I noticed that my database appears to have been upgraded automatically.
The application itself is working fine, except for a backup script that runs every day at midnight. This script runs pg_dump to generate a database backup and then uploads the file to a bucket.
The problem is that the Railway environment seems to be using PostgreSQL client version 16 by default, while my database is now running PostgreSQL 18. Because of this mismatch, the backup job is failing.
I tried setting the Nixpacks config to use PostgreSQL 18, but it does not seem to be taking effect:
nixPkgs = ['nodejs_22', 'yarn', 'postgresql_18']Here are the logs:
pg_dump: error: aborting because of server version mismatch
pg_dump: detail: server version: 18.4 (Debian 18.4-1.pgdg13+1); pg_dump version: 16.14Could you please help me understand how to make the Railway environment use a PostgreSQL 18-compatible pg_dump client for this backup script?
This backup job is critical for our production environment, so I’d appreciate any guidance on the correct Nixpacks configuration or recommended approach.
3 Replies
Status changed to Open Railway • 17 days ago
17 days ago
I recommend you switch to a Dockerfile or Railpack setup for your backup service instead of Nixpacks as it's deprecated. For a backup service I recommend you choose a Dockerfile as it's the cleanest setup, with the most control over your container in this case. You would just have to install postgresql-client, which will install the latest pg_dump version always.
17 days ago
I would add one caveat to the Dockerfile or Railpack route: do not rely on an unpinned postgresql-client package unless you have verified which major version it installs in that image.
The failing mismatch is specifically:
server version: 18.4
pg_dump version: 16.14For backups, the pg_dump binary should be PostgreSQL 18 or newer. The safest pattern is to pin the backup runtime to a PostgreSQL 18 client, either by using a postgres:18 based job image or by installing the PGDG postgresql-client-18 package in the image.
Then verify the deployed backup environment before the scheduled job runs:
command -v pg_dump
pg_dump --versionIf you stay on Nixpacks, the package should be in the setup phase and should extend the detected Node packages:
[phases.setup]
nixPkgs = ["...", "postgresql_18"]If pg_dump --version still reports 16.14 after that, the backup process is not running in the environment you changed, or an older pg_dump earlier in PATH is being used. In that case, move the backup into a small separate service or job image and pin the PostgreSQL 18 client there. That keeps the web app on its normal build path while making the backup runtime deterministic.
sheeki03
I would add one caveat to the Dockerfile or Railpack route: do not rely on an unpinned `postgresql-client` package unless you have verified which major version it installs in that image. The failing mismatch is specifically: ```text server version: 18.4 pg_dump version: 16.14 ``` For backups, the `pg_dump` binary should be PostgreSQL 18 or newer. The safest pattern is to pin the backup runtime to a PostgreSQL 18 client, either by using a `postgres:18` based job image or by installing the PGDG `postgresql-client-18` package in the image. Then verify the deployed backup environment before the scheduled job runs: ```bash command -v pg_dump pg_dump --version ``` If you stay on Nixpacks, the package should be in the setup phase and should extend the detected Node packages: ```toml [phases.setup] nixPkgs = ["...", "postgresql_18"] ``` If `pg_dump --version` still reports `16.14` after that, the backup process is not running in the environment you changed, or an older `pg_dump` earlier in `PATH` is being used. In that case, move the backup into a small separate service or job image and pin the PostgreSQL 18 client there. That keeps the web app on its normal build path while making the backup runtime deterministic.
17 days ago
Installing the latest postgresql-client package is the safest route, as pg_dump is backward compatible.