پس از انتخاب server برای یک read، پیدا کردن connection مناسب هم می‌تواند زیر بار زیاد به گلوگاه تبدیل شود. مقالهٔ Polar Proxy توضیح می‌دهد که بررسی مکرر فهرست connectionها، به‌روزرسانی شمارنده‌های مشترک و رقابت بر سر lock چگونه به هزینهٔ هر query اضافه می‌کنند و این پروژه چه تغییرهایی در این مسیر داده است.
استفادهٔ دوباره از connection صرفاً به آزاد بودن آن وابسته نیست. در این طراحی، چهار بخش باید دقیقاً تطبیق داشته باشند: نسل startup profile، hash مربوط به user و database، هویت startup سمت client و startup options. هویت client فقط وقتی مقایسه می‌شود که startup profile آن را همراه داشته باشد؛ در وضعیت فعلی، endpoint بخشی از این هویت است. مقاله می‌گوید pool عمومی ProxySQL نمی‌تواند همهٔ نیازهای PolarDB، از جمله state مربوط به LSN و transaction، را در بررسی سازگاری بیان کند.
در طراحی Polar Proxy، connection pool مرکزی تنها مالک connectionهای قابل استفادهٔ دوباره برای read است. reader pool فقط server و سیاست‌هایی مثل LSN target، سقف lag و warmup را انتخاب می‌کند. برای هر server، یک index با کلید تطبیق دقیق وجود دارد و جابه‌جایی connection میان فهرست‌های FREE و USED، همراه با تغییر index و شمارنده‌ها، زیر یک mutex انجام می‌شود.
هر worker می‌تواند connection استفاده‌شده را در یک cache از نوع thread-local نگه دارد؛ به‌صورت پیش‌فرض فقط تا پایان همان دور event loop. read بعدی روی همان server، در صورت تطبیق، بدون مراجعه به pool مشترک از آن استفاده می‌کند. این cache مالک دوم connection نیست و connection همچنان در فهرست USED حساب می‌شود. اگر worker دیگری منتظر همان کلید باشد، connection سازگار به pool مشترک برمی‌گردد؛ connection ناسازگار از بین می‌رود.
برای انتخاب میان بیش از دو reader، روش power-of-two-choices یا P2C بار نسبی دو گزینه را مقایسه می‌کند. رسیدن به LSN target جداگانه بررسی می‌شود. در حالت مشخصی با حداقل سه reader هم‌وزن، انتخاب می‌تواند به همان دو گزینه محدود بماند؛ اما اگر شرط‌های لازم برقرار نباشند، بررسی به کل فهرست گسترش پیدا می‌کند.
