Sizing HikariCP maximumPoolSize in Dropwizard: pool limit or database limit first?

Dropwizard's DataSourceFactory uses HikariCP by default, and the documented behavior when the pool is exhausted is that callers wait up to connectionTimeout before a SQLTransientConnectionException is thrown. With connectionTimeout set to zero, waiting threads block indefinitely, which risks starving the Jetty worker pool under sustained load.

The unresolved decision is how to size maximumPoolSize and minimumIdle relative to the database's own connection limit. Raising the pool size shifts the bottleneck to the database; keeping it small pushes queuing into the application. Switching to Commons DBCP2 also changes semantics, since it can fail immediately instead of waiting.

Assume a current Dropwizard 4.x release with the default HikariCP bundle; exact defaults should be verified against the version in use.

1. Should maximumPoolSize be derived from the database's max_connections divided across app instances, or from observed connection.pool.waiting metrics?
2. Is a nonzero connectionTimeout always preferable to zero for protecting the request thread pool?
3. When is DBCP2's fail-fast behavior a better fit than HikariCP's wait-and-timeout model?