Entscheidung: Wie richte ich Connection Pooling ein?

Jede Datenbankverbindung kostet Speicher und Scheduling; eine unkontrolliert wachsende Verbindungsanzahl verlangsamt den Server oder legt ihn sogar lahm. Ein Connection Pool löst das, indem er wenige persistente Verbindungen wiederverwendet. Dieser Baum hilft bei der Entscheidung, wo der Pool sitzt, welcher Modus (Session/Transaction/Statement) gilt und welche Größe richtig ist, und betont, warum in Serverless-Umgebungen ein externer Pooler Pflicht ist.

Wie verbindet sich deine Anwendungsarchitektur?

Die Pooling-Entscheidung beginnt bei der Architektur. Ist es ein einzelner langlebiger Anwendungsprozess (klassischer Server), sind es viele unabhängige Prozesse/Instanzen (Microservices, viele Pods) oder Serverless-/Lambda-Funktionen, die mit jedem Request entstehen und wieder verschwinden? Jede Variante erfordert eine andere Platzierung des Pools.

• Ein/wenige langlebige Anwendungsprozesse
• Viele Prozesse/Instanzen/Pods verbinden sich mit derselben DB
• Serverless / Lambda / kurzlebige Funktionen
• Zeig mir zuerst, wie ich die richtige Poolgröße wähle

Wie wähle ich den Modus des Middleware-Poolers?

Bei vielen Clients hält ein Middleware-Pooler (PgBouncer, ProxySQL) die Verbindungsanzahl auf der DB niedrig. Der Pool-Modus hängt aber von den Funktionen ab, die die Anwendung nutzt: Verlässt du dich auf sessiongebundenen Zustand (Prepared Statements, temporäre Tabellen, SET, Advisory Locks, Funktionen auf Session-Ebene), oder wird alles innerhalb einer einzigen Transaktion abgeschlossen?

• Ich hänge von Session-Zustand ab (SET, temporäre Tabellen, Session Prepared Statements)
• Transaktionen sind kurz und unabhängig; ich halte keinen Session-Zustand

Empfehlung: Connection Pool in der Anwendung

Bei einem/wenigen langlebigen Prozessen deckt eine Pool-Bibliothek in der Anwendung (HikariCP, der eingebaute Pool von Gos database/sql, .NET Connection Pooling) den meisten Bedarf ab. Verbindungen werden einmal geöffnet und immer wieder verwendet.

Empfehlung: Pool richtig dimensionieren

Der Pool sollte weder zu klein (Requests warten) noch zu groß sein. Zu viele Verbindungen erzeugen CPU-Kontextwechsel und Lock-Konkurrenz und senken den Durchsatz. Die Größe ist keine Zahl, die man beliebig erhöht, sondern eine kleine Zahl auf Basis von Kernen und I/O.

Empfehlung: Session-Pool-Modus

Im Session-Modus ist eine Client-Verbindung bis zum Ende ihrer Session an eine Backend-Serververbindung gebunden. Zustand auf Session-Ebene (SET, temporäre Tabellen, Advisory Locks, Session Prepared Statements) bleibt erhalten, die Verbindungsteilung ist aber minimal.

Empfehlung: Transaction-Pool-Modus

Im Transaction-Modus wird dem Client eine Serververbindung nur für die Dauer einer Transaktion geliehen und kehrt danach in den Pool zurück. So können Tausende Clients mit sehr wenigen echten Verbindungen auf der DB arbeiten; es ist der gängigste Modus für hohe Skalierung.

Empfehlung: Für Serverless ist ein externer Pooler Pflicht

Serverless-/Lambda-Funktionen skalieren schnell und jede Instanz öffnet ihre eigene Verbindung; ein Pool in der Anwendung hilft hier nicht, weil Instanzen kurzlebig sind und nichts teilen. Entstehen plötzlich Hunderte/Tausende Instanzen, wird das Verbindungslimit der DB gesprengt. Die Lösung ist ein externer Connection Pool vor der DB.