Zum Inhalt

Skalierung

Umgezogen

Die konkreten Sizing-Profile (Klein/Mittel/Groß/XL), die Pipeline-Ampel und das Anwenden neuer Worker-/Postgres-/Redis-Werte findest du jetzt unter Admin → Wartung → Ressourcen → Leistung — siehe Ressourcen. Diese Seite bleibt als konzeptioneller Leitfaden: wann reicht ein größeres Profil, wann brauchst du mehr?

Wann skalieren?

Anzeichen, dass die aktuelle Größe nicht mehr reicht:

  • Pipeline-Ampel unter Ressourcen → Leistung steht auf gelb oder rot
  • Die RAM-Verteilung unter Ressourcen → RAM zeigt einen Dienst (meist die Datenbank) dauerhaft nahe am Server-Limit
  • Neue Check-Ergebnisse kommen sichtbar verzögert im Frontend an

Erste Reaktion: ein Sizing-Profil höher wählen (siehe Ressourcen → Leistung). Das deckt die meisten Fälle ab, ohne dass du einzelne .env-Variablen von Hand anfassen musst.

Vertikal vs. horizontal

Pfad Vor- / Nachteil
Vertikal — größeres Sizing-Profil, mehr RAM/CPU am Server Einfach (ein Klick + Container-Neustart), kein Architektur-Umbau, irgendwann hardware-limitiert
Horizontal — mehrere API-Container, externe Datenbank/Redis Mehr Komplexität, dafür Wachstum weit über einen einzelnen Server hinaus

Empfehlung: erst vertikal bis zur größten sinnvollen Server-Konfiguration skalieren (XL-Profil, 16 GB+ RAM). Erst danach horizontal denken.

Externalisieren (Postgres / Redis)

Bei sehr großen Setups kann es sinnvoll sein, Postgres oder Redis aus dem Compose-Stack zu nehmen und einen dedizierten oder managed Dienst zu nutzen. Grober Ablauf:

  1. Externe Instanz aufsetzen (gleiche Postgres-Major-Version, TimescaleDB-Extension installiert)
  2. Daten migrieren (Dump aus dem eingebauten Backup einspielen)
  3. Verbindungs-Variable in der .env auf die externe Instanz umstellen
  4. Den entsprechenden Dienst aus dem eigenen Compose-Stack entfernen

Dieser Pfad ist nicht offiziell durchgetestet — vorher unbedingt an einer Test-Instanz durchspielen, inklusive eines vollständigen Restore-Drills.

Anschluss