# GCP: Postgres connection timeout during n8n startup on Cloud Run (Cloud SQL Unix socket)

**URL:** <https://community.n8n.io/t/gcp-postgres-connection-timeout-during-n8n-startup-on-cloud-run-cloud-sql-unix-socket/306096>\
**Category:** Questions\
**Tags:** bug:unconfirmed\
**Created:** [August 4, 2026, 2:56pm UTC](https://community.n8n.io/t/gcp-postgres-connection-timeout-during-n8n-startup-on-cloud-run-cloud-sql-unix-socket/306096 "2026-08-04T14:56:03Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![rgrzesk](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/rgrzesk/32/114865_2.png) [@rgrzesk](https://community.n8n.io/u/rgrzesk)\
**Post date:** [August 4, 2026, 2:56pm UTC](https://community.n8n.io/t/gcp-postgres-connection-timeout-during-n8n-startup-on-cloud-run-cloud-sql-unix-socket/306096/1 "2026-08-04T14:56:03Z")

</div>

Description  
We observed a one-time startup incident in n8n on Google Cloud Run with PostgreSQL on Cloud SQL (Unix socket connection).

Environment

- n8n version: 2.32.5
- Runtime: Google Cloud Run (Gen2)
- Region: europe-west3
- Database: PostgreSQL on Cloud SQL
- Connection method: Unix socket under /cloudsql

What happened

- During one startup window, n8n logged repeated:
  - `Error: timeout exceeded when trying to connect`
  - stack traces pointing to `pg-pool`, `@n8n/typeorm`, and `@n8n/db` connection acquisition paths.

- In that same window:
  - root endpoint could return 200
  - some API calls returned 500 / high latency
  - DB-dependent background tasks reported failures

- A manual redeploy was performed.
- Shortly after redeploy, the service stabilized and has worked normally since.

---

<div class="post-metadata">

**Author:** ![n8n](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/n8n/32/196425_2.png) [@n8n](https://community.n8n.io/u/n8n)\
**Post date:** [August 4, 2026, 2:56pm UTC](https://community.n8n.io/t/gcp-postgres-connection-timeout-during-n8n-startup-on-cloud-run-cloud-sql-unix-socket/306096/2 "2026-08-04T14:56:44Z")

</div>

Hey @rgrzesk, while you wait for a response, here are some things that might help:

> **Suggested resources**
>
> _Automatically matched to your question._
> 
> **Docs:**
> 
> - [Database](https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/database#how-database-connection-recovery-works)
> - [Database](https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/database#postgresql)
> 
> **Forum:**
> 
> - [Database connection lost & N8N shutdown after SFTP timeout](https://community.n8n.io/t/266482)
> - [Intermittent ECONNRESET / socket hang up errors in HTTP Request node on Google Cloud Run (Docker)](https://community.n8n.io/t/238378)
> - [N8N errors after shifting to V2](https://community.n8n.io/t/278006)

@Mayank1024, @Websensepro, @tamy.santos - you’ve helped with similar issues before, can you take a look?

_Automatically suggested by n8n’s community bot. It’s a pilot - [please share feedback here](https://community.n8n.io/t/pilot-forum-helper-bot/304669)._

---

<div class="post-metadata">

**Author:** ![achamm](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/achamm/32/143734_2.png) [@achamm](https://community.n8n.io/u/achamm)\
**Post date:** [August 4, 2026, 2:59pm UTC](https://community.n8n.io/t/gcp-postgres-connection-timeout-during-n8n-startup-on-cloud-run-cloud-sql-unix-socket/306096/3 "2026-08-04T14:59:17Z")

</div>

Hi @rgrzesk It looks like your just reporting a bug, correct? Your instance is all good now?

---

<div class="post-metadata">

**Author:** ![kjooleng](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/kjooleng/32/184045_2.png) [@kjooleng](https://community.n8n.io/u/kjooleng)\
**Post date:** [August 4, 2026, 3:05pm UTC](https://community.n8n.io/t/gcp-postgres-connection-timeout-during-n8n-startup-on-cloud-run-cloud-sql-unix-socket/306096/4 "2026-08-04T15:05:37Z")

</div>

@rgrzesk

Looks more like an incident report to me.  
Perhaps you would like to raise the issue with your provider

---

<div class="post-metadata">

**Author:** ![Anshul\_Namdev](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/anshul_namdev/32/178229_2.png) [@Anshul\_Namdev](https://community.n8n.io/u/Anshul_Namdev)\
**Post date:** [August 4, 2026, 5:51pm UTC](https://community.n8n.io/t/gcp-postgres-connection-timeout-during-n8n-startup-on-cloud-run-cloud-sql-unix-socket/306096/5 "2026-08-04T17:51:32Z")

</div>

Hi @rgrzesk  
“timeout exceeded when trying to connect” comes from pg-pool’s acquisition timeout, so the pool never handed out a client within `DB_POSTGRESDB_CONNECTION_TIMEOUT`, rather than the Cloud SQL socket being unreachable. `DB_POSTGRESDB_POOL_SIZE` defaults to 2, and on a single Cloud Run instance the startup queries plus incoming traffic queue behind those two connections, which is why the root endpoint stayed 200 while the DB-backed calls went 500. Raise both on the revision:

```auto
DB_POSTGRESDB_POOL_SIZE=10
DB_POSTGRESDB_CONNECTION_TIMEOUT=60000

```

Then cap Cloud Run container concurrency to roughly what the pool can serve (10 to 20), so a spike can’t outrun it again. Cloud Run allows 100 connections per instance to Cloud SQL, so 10 stays well inside that.

> **[Database | Deploy | n8n Docs](https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/database)**
>
> Set up and configure databases with environment variables for your self-hosted n8n instance.

---

<div class="post-metadata">

**Author:** ![tamy.santos](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/tamy.santos/32/153776_2.png) [@tamy.santos](https://community.n8n.io/u/tamy.santos)\
**Post date:** [August 5, 2026, 1:47pm UTC](https://community.n8n.io/t/gcp-postgres-connection-timeout-during-n8n-startup-on-cloud-run-cloud-sql-unix-socket/306096/6 "2026-08-05T13:47:58Z")

</div>

> [@rgrzesk](#):
>
> - the service has stabilized and has been operating normally ever since.

I’m glad the service has stabilized and has been operating normally ever since 🙂

---

<div class="post-metadata">

**Author:** ![rgrzesk](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/rgrzesk/32/114865_2.png) [@rgrzesk](https://community.n8n.io/u/rgrzesk)\
**Post date:** [August 5, 2026, 2:02pm UTC](https://community.n8n.io/t/gcp-postgres-connection-timeout-during-n8n-startup-on-cloud-run-cloud-sql-unix-socket/306096/7 "2026-08-05T14:02:19Z")

</div>

Thanks! I will tune the CloudRun this way.  
However, what worries me - it just happened all of a sudden and the instance is up from 6 months, so far working without any issues.

---

<div class="post-metadata">

**Author:** ![Cloudrocket](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/cloudrocket/32/188664_2.png) [@Cloudrocket](https://community.n8n.io/u/Cloudrocket)\
**Post date:** [August 8, 2026, 6:22am UTC](https://community.n8n.io/t/gcp-postgres-connection-timeout-during-n8n-startup-on-cloud-run-cloud-sql-unix-socket/306096/8 "2026-08-08T06:22:43Z")

</div>

A pg-pool acquisition timeout tells you that no client became available before the deadline. It does not prove the pool was too small. Because this happened once after six stable months, raising the pool may only move pressure to Cloud SQL.

Line up the affected revision with the Cloud SQL connection graph and the Cloud Run startup log for that timestamp. If both existing connections were busy while requests queued, a larger pool or lower container concurrency is reasonable. If new connections were timing out, the pool size is not the root cause.

Change one limit at a time and keep the previous value recorded. Otherwise the next incident will not tell you which change helped.

---

<div class="post-metadata">

**Author:** ![system](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/system/32/195824_2.png) [@system](https://community.n8n.io/u/system)\
**Post date:** [November 6, 2026, 6:23am UTC](https://community.n8n.io/t/gcp-postgres-connection-timeout-during-n8n-startup-on-cloud-run-cloud-sql-unix-socket/306096/9 "2026-11-06T06:23:37Z")

</div>

Closed on November 6, 2026, 6:23am UTC

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
