Need a single, prescriptive fix for Postgres read ECONNRESET on public DB URLs (delete one row)

Context: I run a maintenance job that connects to ~15 PostgreSQL databases on Railway to delete a single row in a table by URL:

DELETE FROM auctions WHERE link = $1;

Behavior: Most DBs work, but two specific DBs intermittently fail with read ECONNRESET. This happens locally and on Railway. We are using the public database URL because the app and these databases are in different Railway projects.

What’s already implemented (still fails on those two DBs):

• Tried pg (Client and Pool) and Sequelize v6 (postgres dialect).

• Public pooled vs direct endpoints, keepAlive: true, limited concurrency, retries with backoff, SELECT 1 preflight, SET statement_timeout '30s'.

• SSL variations: sslmode=no-verify, rejectUnauthorized:false.

• Fallback flow that opens a brand-new pg Client per attempt (connect → ping → delete → end) for the two problematic DBs, processed sequentially.

• Restarts of the DB services. Postgres logs have included: invalid length of startup packet, could not receive data from client: Connection reset by peer, and previously CERT_HAS_EXPIRED.

Request: Provide one supported, prescriptive solution that ensures a stable connection over public URLs across projects so this single-row DELETE completes reliably without ECONNRESET—including the exact endpoint type to use and the precise connection string/flags or server-side configuration required.