It's unclear from the question, but they were apparently looking for a very small number. But is that connection timeout, or query timeout, or something else?

It's unclear from the question, but they were apparently looking for a very small number. But is that connection timeout, or query timeout, or something else? If you have long-running complex data processing or ingestion jobs, query timeouts could well be measured in minutes or hours. So a small number doesn't make sense there, and the connection technically doesn't timeout. For connection timeouts, if you run a connection pool then timeouts of a few seconds or more could be fine and be the difference between the system being completely down vs just slow in case the load / contention unexpectedly increases. Not great of course and it won't hold for long, but might help in some very specific bursty scenarios. If you are able to safely re-use the connections in the pool most of the time the timeout matters even less. Reusing connections is usually possible, but it depends on the database and what errors require establishing a new DB connection. And of course with a pool you actually have 2 'connection timeouts': one for establishing a new connection to the DB and a second one for acquiring a connection from the pool. The second one is usually most relevant for an application, but both matter. But even without a pool a higher number (say a few minutes) could possibly make sense given a specific scenario. A database with a connection limit is equivalent to decrementing a semaphore (acquiring a lock), and there are cases where you'd want to wait for just a bit longer to acquire that lock instead of just timing out. A slightly longer timeout won't hurt if e.g. you implement a retry mechanism anyways instead of aborting. Not saying long timeouts are a sign of great engineering, but context matters a lot for these sorts of questions.