L'apertura di una nuova connessione richiede un tempo lungo : le librerie client devono stabilire a quale server comunicare, quindi aprire una negoziazione con quel server per ottenere una connessione iniziale, quindi riavviare le credenziali e avanti per autenticare il client, quindi avviare una sessione di database e [finalmente] configurare quella sessione nel modo desiderato dall'applicazione.
Lento!
Le connessioni in pool consentono di eliminare la maggior parte (ma non tutte) di quel sovraccarico con nessun lavoro aggiuntivo sulla parte dell'applicazione. La maggior parte della gestione degli errori non è in grado di accedere al database in primo luogo.
Ottimo per le applicazioni web, in cui il server web deve entrare, fare qualcosa e uscire di nuovo, più e più volte per una moltitudine di client diversi.
Non così buono per, diciamo, un servizio di Windows che è in esecuzione "in background" 24x7 ma dove il database sottostante "scompare" per "un po 'di tempo" ogni notte per le attività di manutenzione e altre attività di manutenzione.
Certo, si potrebbe chiudere il servizio mentre sta succedendo, ma (in assenza di qualsiasi modo gestito di farlo al momento) la nostra soluzione era quella di costruire l'applicazione per trattare il suo database come un'entità transitoria. Stabiliva una connessione al database quando poteva e quindi lo teneva aperto e, ogni volta che voleva usare il database, quasi si aspettava che fosse "scomparso". E sì, la gestione degli errori aveva bisogno di era molto più complicato, ma quel servizio è stato eseguito abbastanza felicemente per un decennio e mezzo! (OK, not continuamente, l'host viene riavviato ogni mese per il patching).