Why max_connections is NOT the solution in Odoo

🚨 The automatic reflection when Odoo is slow

When errors like these appear:

• FATAL: too many connections

• intermittent latency

• Odoo is "thinking"

The typical reaction is:

max_connections = 500

👉 It seems logical.

👉 It is almost always a mistake.

🧠 Why this setting is so tempting

Because:

• the error mentions "connections"

• the parameter is called max_connections

• changing it is easy

• PostgreSQL restarts without complaining

But PostgreSQLdoes not warn youthat you just degraded the system.

🔌 What max_connections really means

In PostgreSQL:

• 1 connection = 1 process

• each process consumes:

  • memory

  • CPU

  • internal structures

Even an idle connection:

• is not free

• reserves memory

• participates in scheduling

📉 El coste real por conexión

Depending on the configuration:

• 5–15 MB per connection (minimum)

• plus work_mem

• plus temporary buffers

Real example:

300 connections × 10 MB ≈ 3 GB of RAM

And thatwithout doing anything.

🧨 The cascading effect in PostgreSQL

When increasing max_connections:

• more processes compete for CPU

• more context switching

• more cache misses

• worse overall latency

Result:

low CPU, high RAM, slow system.

⚠️ Odoo empeora este escenario

Odoo:

• keeps connections open

• holds transactions

• does not release quickly

So:

• PostgreSQL cannot recycle resources

• connections accumulate

• latency becomes unpredictable

❌ The false "temporary fix"

Sometimes this happens:

1. you increase max_connections

2. you restart PostgreSQL

3. "it works better"

4. a few hours later, it fails again

Why?

👉 Becauserestarting frees memory, not because the tuning is correct.

🧪 Comparative real example

Without PgBouncer

• max_connections = 400

• 150 active connections

• RAM saturated

• variable latency

With PgBouncer

• max_connections = 100

• 20 real connections

• stable RAM

• consistent latency

👉 Fewer connections = better performance.

🧠 PostgreSQL prefers few well-used connections

PostgreSQL scales better with:

• few connections

• well reused

• with pooling

Not with:

• hundreds of idle processes

• fragmented memory

• constant contention

🧩 So, what is the solution?

It is not:

• more hardware

• more workers

• more connections

It is:

decoupling logical connections from real connections

This is achieved with:

• PgBouncer

• correct pool_mode

• well-sized pools

👉 Everything we are building in this course.

🔗 Related links

• Por qué Odoo es lento con muchos usuarios

• Cómo Odoo gestiona las conexiones a PostgreSQL

• Qué es PgBouncer y por qué Odoo lo necesita

• Configuración básica de PgBouncer optimizada para Odoo

📌 Conclusion

Increasing max_connections:

• is easy

• seems logical

• almost always worsens the problem

In Odoo:

• the problem is not the limit

• it ishow connections are used

👉 PostgreSQL does not need more connections.

👉 It needsfewer, better used.

👉 Recommended next chapter

How to calculate the ideal pool_size of PgBouncer for Odoo

There we get into:

• real numbers

• workers

• concurrent users

• crons

• producción sin adivinanzas

Next chapter ->