The issue. n8n is configured to use TCP proxy variables (RAILWAY_TCP_PROXY_DOMAIN and RAILWAY_TCP_PROXY_PORT), but Postgres likely doesn't have a TCP proxy enabled. Let me verify:

Solution: Change n8n to use the private internal domain instead of the TCP proxy. This is more reliable for internal service-to-service communication:

Your diagnosis is right, and switching to the private domain is the correct fix. Concretely, in your n8n service variables, point the DB at Postgres over the private network instead of the TCP proxy:

DB_POSTGRESDB_HOST=${{Postgres.RAILWAY_PRIVATE_DOMAIN}}

DB_POSTGRESDB_PORT=5432

DB_POSTGRESDB_DATABASE=${{Postgres.PGDATABASE}}

DB_POSTGRESDB_USER=${{Postgres.PGUSER}}

DB_POSTGRESDB_PASSWORD=${{Postgres.PGPASSWORD}}

(Use reference variables like above rather than hardcoding — they follow the DB if credentials change.) Private networking is faster, free (no egress billing), and doesn't depend on the public TCP proxy being enabled at all. Redeploy n8n after changing the variables — variable changes only take effect on a new deploy.

The TCP proxy variables only work if a TCP proxy is actually configured on the Postgres service (Settings → Networking), and the proxy route is public egress — you'd be paying egress for every query. Private domain is the recommended setup for service-to-service traffic within a project.