Knex connection timeout issue on Strapi start

System Information
  • Strapi Version: 4
  • Database: Postgresql 13

I’ve been experiencing a similar issue to that described here: #11860

This is occurring when attempting to deploy to a Digital Ocean environment. I’ve tried all sorts of settings for the connection pool settings on the Postgresql database and in database.js to no avail. The strapi start process eventually fails with the knex connection timeout error.

Is there a minimum amount of DB RAM and size of connection pool Strapi needs to be able to start and run migrations for updated/created models? I’m just wondering if a Strapi instance with many collections and components is not suited to a 1GB database instance?

1 Like

I’m experiencing the same issue as well.
Every new deployment to Digital Ocean fails due to Knex timeout.

We are running Postgress 14 on DO with following specs:
DB: 1 CPU + 2 GB + 25 GB Disk
Strapi: 4GB + 80 GB Disk

No amount of tweaking the connection pool configuration and associated pool settings in database.js was able to fix this issue for me. In the end I dropped using Postgresql in favour of MySQL on Digital Ocean and this has resolved the issue. In order to get Strapi working with MySQL on Digital Ocean I did have to contact Digital Ocean support through the online support mechanism and request they make the following setting change on my managed MySQL database:

Disable the requirement for all tables to have a primary key. i.e. SQL_REQUIRE_PRIMARY_KEY = 0

Experiencing the same issue.

I’m not sure if this would be helpful to anyone, but I got this same error. On my non-dockerized local machine, I had a project that was using Strapi v3, and a separate project that was using Strapi v4. Two different directories. When I tried starting the project that was using v3, it was throwing me this Knex error. I had to get rid of the project using v4, and then the project using v3 started working again.

Are you using DigitalOcean App Platform? I ran into the same issue there.

You have to keep in mind that the old deployment is still live (taking up connections) when you are building and deploying the new one. When I set the maximum connection limit to 1/2 - 3/4 of the available connections it works perfectly fine. Note that, if you’re trying to deploy during busy times when all the connections are taken it will fail again if you occupy more than halve of the connections.

Using latest v4 with only this config

 pool: {
        min: 0,
        max: 15,
}

For the cheapest database node with 22 available connections.

If you have already tried all pool configurations, try adding acquireConnectionTimeout with a large value.

module.exports = ({ env }) => ({
connection: {
client: ‘postgres’,
connection: {
host: env(‘DATABASE_HOST’, ‘127.0.0.1’),
port: env.int(‘DATABASE_PORT’, 5432),
database: env(‘DATABASE_NAME’, ‘strapi’),
user: env(‘DATABASE_USERNAME’, ‘strapi’),
password: env(‘DATABASE_PASSWORD’, ‘strapi’),
schema: env(‘DATABASE_SCHEMA’, ‘public’), // Not required
ssl: env(‘DATABASE_SSL’, false)
},
acquireConnectionTimeout: 1000000,
pool: {
min: 0,
max: 1,
acquireTimeoutMillis: 300000,
createTimeoutMillis: 300000,
destroyTimeoutMillis: 300000,
idleTimeoutMillis: 30000,
reapIntervalMillis:1000,
createRetryIntervalMillis: 2000
},
debug: false,
},
});