Knex: getting "Knex: Timeout acquiring a connection. The pool is probably full." error

I am also facing this issue.

I have the same problem.

The solution is to isolate the source and fix it. This is not a "query" error, but rather an application architecture issue. The error occurs when knex is unable to acquire a connection within (default) 60 seconds, and most likely the reason for that is that the pool is full.

In other words there are many things that can cause the error. Two of the most common are:

1. You forget to commit transactions / forget calling .transacing(trx) on query builders while already at max pool which not only causes the transaction to idle but also throws the error as no connection could be acquired.
2. The pool is continiously kept busy at max capacity for at least (default) 60 seconds non-stop, for instance due to heavy traffic or long running procedures.

You should look over your database state when this error occurs - are there a lot of idle connections? are there too many connections? etc.

I am also facing this error.

rejecter(new _bluebird2.default.TimeoutError('Knex: Timeout acquiring a connection. The pool is probably full. ' + 'Are you missing a .transacting(trx) call?')); ^ TimeoutError: Knex: Timeout acquiring a connection. The pool is probably full. Are you missing a .transacting(trx) call?

While we are working to dig our architecture connections, theres a way to prevent this error from crash the application? Or at least the error could point out the stack ?

@rsfernandes As long as you use catch handlers on your builders I don't see how this error would crash the entire application.

As for the stack, I recommend longStackTraces. There's nothing built into knex specifically for this error stack.

FWIW I got this error with an AWS Aurora database service, and it was caused by auto shutdown feature which terminates the database after inactivity (auto-startup of the database takes like a minute or so, and that caused knex to time out)

https://github.com/tgriesser/knex/issues/3159 There is list of some work around suggestions for aurora.

@wubzz

1. The pool is continiously kept busy at max capacity for at least (default) 60 seconds non-stop, for instance due to heavy traffic or long running procedures.

If this is the issue, what are possible recommendations to take if cannot simply do less work? 😅

Increase the timeout or max capacity?

My problem was not with knex but rather with the security group inbound rule on my aws RDS. It was set to my local machine ip address only and so I could not connect to it from the ec2 instance. was frustrating because the error message was not helpful.
If you have this error message, it could be related to the fact that knex cannot establish a connection. so check your networks too!

Yeah, I suppose that can happen if connection is blocked completely... maybe setting up different connection timeout and acquite timeout could distinguish between these two cases.

I solved the problem with these versions:

"knex": "^0.21.1",
"objection": "^2.1.3",
"pg": "^8.0.3"

You may have to switch to Node 12 NOT Node 14

I had a database pool limit, I could fix the issue by setting min and max

I had the same issue on my mac. i was running knex from command line terminal and suddenly started seeing this Knex: Timeout... issue. I figured out that the problem was moving to zsh shell instead of bash. I've been using bash for a long time, and i recently tried switching to zsh per Apple guidelines. As soon as i went back to bash it was fixed.

Hope it helps someone.

You may have to switch to Node 12 NOT Node 14

This worked for me on mac docker-compose node:12 instead of node (v14). Thanks.

I was trying to enforce using the server's node version by using nvm exec 12 node ./src/index... and was having the error above.

By launching node directly, the error disappeared and the connection was established.

So make sure you are using a plain, normal setup and maybe node 12.

@batadamnjanovic you saved me after two full days of research. TY !!