Here are some bechmark numbers of the different implementations provided for the ConnectionCache interface. These were all done with 8 threads cycling through connections, for different pool sizes. 

NONE:

Benchmark (jdbcUrl) (poolSize) (poolType) Mode Cnt Score Error Units
ConnectionBenchmark.cycleConnection jdbc:stub 5 agroal thrpt 16 9386.086 ± 452.665 ops/ms
ConnectionBenchmark.cycleConnection jdbc:stub 50 agroal thrpt 16 8172.370 ± 234.264 ops/ms
ConnectionBenchmark.cycleConnection jdbc:stub 500 agroal thrpt 16 8536.765 ± 200.999 ops/ms

SINGLE:

Benchmark (jdbcUrl) (poolSize) (poolType) Mode Cnt Score Error Units
ConnectionBenchmark.cycleConnection jdbc:stub 5 agroal thrpt 16 12764.439 ± 543.477 ops/ms
ConnectionBenchmark.cycleConnection jdbc:stub 50 agroal thrpt 16 13766.563 ± 726.249 ops/ms
ConnectionBenchmark.cycleConnection jdbc:stub 500 agroal thrpt 16 12290.670 ± 685.952 ops/ms

FIXED 4:

Benchmark (jdbcUrl) (poolSize) (poolType) Mode Cnt Score Error Units
ConnectionBenchmark.cycleConnection jdbc:stub 5 agroal thrpt 16 10602.280 ± 797.598 ops/ms
ConnectionBenchmark.cycleConnection jdbc:stub 50 agroal thrpt 16 12992.036 ± 1154.738 ops/ms
ConnectionBenchmark.cycleConnection jdbc:stub 500 agroal thrpt 16 12785.276 ± 1201.250 ops/ms

FULL:

Benchmark (jdbcUrl) (poolSize) (poolType) Mode Cnt Score Error Units
ConnectionBenchmark.cycleConnection jdbc:stub 5 agroal thrpt 16 9155.050 ± 440.170 ops/ms
ConnectionBenchmark.cycleConnection jdbc:stub 50 agroal thrpt 16 13752.164 ± 1798.527 ops/ms
ConnectionBenchmark.cycleConnection jdbc:stub 500 agroal thrpt 16 13013.081 ± 531.361 ops/ms

Here we can see that the connection cache is effective. When the number of connections is smaller than the number of threads, the 'single' implementation works best and as the number of connection increases, the 'fixed' and 'full' implementations start to outperform.

I propose to change the default implementation of ConnectionCache to 'single' given

1. the simplicity of the implementation (therefore less prone to bugs)
2. consuming less memory
3. the fact that it is not far behind even when the number of connections is far greater than the number of threads