多くのJDBCドライバでは、ある時点でたった1つのスレッドだけがConnectionオブジェクトを使用できるという問題があります。あるスレッドが結果を受け取っている時に別のスレッドが問い合わせを送る場合は別です。このことはデータベースエンジンにとって有害です。
PostgreSQL 6.4で、ドライバ全体をスレッドセーフにしました。（標準JDBCは6.3の段階でスレッドセーフでしたが、Fastpath APIはそうではありませんでした。） 従って、アプリケーションで複数のスレッドを使用する場合、同時にデータベースを使用するスレッドがないことを確実にするための複雑なアルゴリズムを考える必要がありません。
スレッドが別のスレッドが使用している時に接続を使用しようとすると、他のスレッドが完了するまでその操作は待たされます。標準SQL文の場合、操作とは文を送信し、何らかのResultSetを（完全に）受け取ることです。Fastpath呼び出し（つまり、LargeObjectからブロックを読むこと）の場合、それはブロックを送信する、または、受け取る瞬間です。
これはアプリケーションやアプレットでは優れていますが、サーブレットの場合は性能に関する問題を発生させます。サーブレットでは、その接続に重い負荷をかけることができます。問い合わせを行なう複数のスレッドがある場合、それぞれは待たされ、そして、それがその次に行なわれるとは限りません。
これを解消するために、Connectionオブジェクトのプールを作成することを勧めます。接続をそのスレッドに渡し、その接続に使用中と印をつけます。空き接続がなければ、接続を開きます。スレッドが処理を終えた段階で、管理クラスに返却します。管理クラスはその接続を閉じることも、また、プールに追加することもできます。また、管理クラスは接続が現在も有効かどうか点検し、もし無効であればそれをプールから削除します。
ですので、サーブレットでは、1つの接続を使用するかプールを使用するかは設計者に依存します。プールの場合の利点は、そのスレッドが1つのネットワーク接続が原因となるボトルネックの影響を受けないことです。欠点は、バックエンドプロセスが各接続用に生成されますので、サーバの負荷が増大することです。設計者、そしてそのアプリケーションの要求仕様に依存します。