a month ago
Hello Railway Support Team,
I'm experiencing a persistent connectivity issue between two services in my Railway project that I need help resolving.
PROJECT SETUP:
- Project ID:
- Service 1: n8n (self-hosted workflow automation) - running successfully
- Service 2: Postgres database - running successfully
- Both services are in the same Railway project and environment
ISSUE:
My n8n service cannot connect to the Postgres database despite trying multiple approaches:
1. INTERNAL NETWORK CONNECTION (postgres.railway.internal):
- Error: "No testing function found for this credential"
- This occurs both when testing credentials and when executing queries
- Query execution returns: "column 98274834633988fbb7d6b969f6fe45fd8bdefabe8.role does not exist"
- This suggests a database schema corruption or authentication issue
2. PUBLIC TCP PROXY CONNECTION:
- Generated public domain: postgres-production-a15c.up.railway.app:5432
- Same connection failures occur
- Credentials are verified correct (user: railway, database: railway)
CONNECTION DETAILS USED:
- Host: postgres.railway.internal (internal) or postgres-production-a15c.up.railway.app (public)
- Database: railway
- User: railway
- Password: [verified from PGPASSWORD variable]
- Port: 5432
- SSL: Both "Disable" (internal) and "Allow" (public) modes tested
TROUBLESHOOTING ALREADY ATTEMPTED:
- Verified all credentials match the Railway-provided variables (PGHOST, PGUSER, PGPASSWORD, PGDATABASE)
- Recreated credentials multiple times from scratch
- Tested both private and public networking endpoints
- Confirmed both services are running and healthy
- Attempted direct SQL queries via n8n workflow execution
OBSERVATIONS:
- The private network hostname (postgres.railway.internal) resolves but connections fail
- The error message suggests either:
a) The services aren't properly networked within Railway's private network, OR
b) There's a database-level issue with the Postgres instance
EXPECTED BEHAVIOR:
n8n should be able to connect to Postgres using postgres.railway.internal since both services are in the same project, or alternatively via the public TCP proxy endpoint.
QUESTION:
Can you verify that:
1. Both services are properly networked within the Railway private network?
2. The Postgres database schema is healthy and not corrupted?
3. The internal DNS (postgres.railway.internal) is correctly resolving from the n8n service?
I've temporarily moved to an external database provider (Supabase) to unblock my workflow development, but I'd prefer to keep everything within Railway for better performance and simplified architecture.
Thank you for your assistance.
Best regards,
John Kourkoutas
3 Replies
a month ago
Hey there! We've found the following might help you get unblocked faster:
If you find the answer from one of these, please let us know by solving the thread!
a month ago
Hello,
can you check these two things:
make sure n8n and Postgres are in the same environment (internal DNS won’t work otherwise), and
test Postgres directly with
railway run psql.If the schema is broken there, restore/reset the DB; if not, it’s just a networking mismatch and disabling SSL internally should fix it.
a month ago
Hey John,
That's an incredibly well-documented report of the issue. The advice from idiegea21 is the perfect first step: using railway run psql to connect directly is the best way to confirm that the database instance itself is healthy and not corrupted.
However, you've provided a critical clue in your error message that points to a very specific and known configuration issue within n8n itself, not with Railway's networking.
The Real Meaning of Your Error Message
The key to solving your problem is this line:
Query execution returns: "column 98274834633988fbb7d6b969f6fe45fd8bdefabe8.role does not exist"
This is not a database corruption error or a networking failure. This is a known issue with how n8n constructs its SQL queries under a specific condition.
The long hexadecimal string (
9827...) is the internal ID of the credential you created within n8n for this database.This error almost always happens when a value has been entered into the "Current Schema" (or "DB Schema") field in your n8n Postgres credential settings. When that field is set, n8n tries to prefix the table name (
role) with what it thinks is the schema, but in this case, it's incorrectly using its own internal credential ID.
How to Fix It
The solution is to remove the incorrect schema configuration from your n8n credential.
Log in to your n8n instance.
Navigate to the Credentials section on the left sidebar.
Find and open your credential for the Railway Postgres database to edit it.
Look for the field named "Current Schema" (it might also be called "DB Schema").
Delete any value in this field. It must be completely blank.
Click Save.
Try the connection test again. It should now succeed.
By leaving the "Current Schema" field blank, you allow Postgres to use its default search_path, which correctly finds tables in the public schema.
This should resolve the connectivity issue entirely. It’s an application-level configuration fix, not an issue with Railway's private network or your database instance.