- Self-Hosting von Postgres ist weder kompliziert noch riskant und günstiger als Managed Services bei freierer Performance-Abstimmung
- Die meisten Cloud-Datenbankdienste betreiben leicht modifiziertes Open-Source-Postgres, der eigentliche Unterschied liegt im Grad der Betriebsautomatisierung
- In realen Betriebsfällen verarbeitet selbst gehostetes Postgres Tausende Nutzer und Dutzende Millionen Abfragen stabil, bei sehr geringem Wartungsaufwand
- Durch die Preissteigerungen bei Managed Services wie AWS RDS kann man zum gleichen Preis einen Server mit deutlich höherer Ausstattung selbst betreiben
- Für mittelgroße Teams ohne allzu komplexes Infrastrukturmanagement ist Self-Hosting eine realistische Alternative in Bezug auf Kosteneffizienz und Performance
Der Wandel der Cloud-zentrierten Erzählung
- Früher betrieben die meisten Unternehmen ihre Datenbanken direkt auf eigenen Servern, was eine schnelle Architektur mit geringer Netzwerklatenz ermöglichte
- In den 1980er- bis 2000er-Jahren befanden sich Applikationsserver und Datenbankserver oft auf derselben physischen Hardware
- Die Einführung von Amazon RDS (2009) wurde als attraktives Angebot gesehen, das Backups, Patches und Monitoring automatisierte
- Anfangs ließ sich damit der Betriebsaufwand bei ähnlichen Kosten wie für dedizierte Server reduzieren
- Mit der beschleunigten Cloud-Einführung nach 2015 verbreitete sich die Wahrnehmung, dass eigenes Infrastrukturmanagement ineffizient sei
- AWS übernimmt die Infrastruktur, Entwickler konzentrieren sich auf die Applikationslogik – dieses Modell wurde zum Standard
- Im Jahr 2025 sind die RDS-Preise deutlich gestiegen, sodass man zum gleichen Preis dedizierte Server mit wesentlich höherer Ausstattung mieten kann
- Beispiel: Eine Instanz vom Typ db.r6g.xlarge (4 vCPU, 32GB RAM) kostet 328 US-Dollar pro Monat; dafür lässt sich ein Server mit 32 Kernen und 256GB RAM mieten
Der tatsächliche Aufbau von Managed Services
- AWS RDS ist im Kern Standard-Postgres mit ergänztem AWS-spezifischem Monitoring und Backup-System
- Enthalten sind EBS-Snapshot-basierte Backups, Konfigurationsmanagement über Chef/Puppet/Ansible, Connection Pooling mit PgBouncer, CloudWatch-Monitoring und Skripte für automatisches Failover
- Technisch ist diese Architektur nicht besonders komplex; der zentrale Mehrwert liegt in Betriebsautomatisierung und komfortabler Erstbereitstellung
- Bei der Migration von RDS auf Self-Hosting mit Servern gleicher Spezifikation war die Performance identisch oder sogar besser
- Parameter, die in RDS eingeschränkt waren, konnten nun direkt angepasst und für bessere Performance optimiert werden
Betriebsaufwand beim Self-Hosting
- Die Migration auf einen DigitalOcean-Server mit 16 vCPU / 32GB RAM / 400GB Speicher dauerte etwa 4 Stunden; danach lief der Betrieb stabil
- Produkte mit hohen Verfügbarkeitsanforderungen benötigen rund 30 Minuten Administrationszeit pro Monat, Dienste mit wenig Traffic lassen sich vollständig automatisieren
- Regelmäßiger Wartungszyklus
- Wöchentlich (10 Minuten): Backups prüfen, Slow-Query-Logs durchsehen, freien Speicherplatz kontrollieren
- Monatlich (30 Minuten): Sicherheitsupdates einspielen, Aufbewahrungsrichtlinien für Backups prüfen, Kapazitätsplanung
- Vierteljährlich (2 Stunden): Monitoring-Dashboards aktualisieren, Konfiguration optimieren, Wiederherstellung testen
- Für Störungen ist man selbst verantwortlich, allerdings treten auch bei RDS Ausfälle auf, auf die am Ende ebenfalls Entwickler reagieren müssen
- Im Eigenbetrieb lassen sich Zeitpunkt von Updates und Risikofenster selbst steuern, was die Absicherung der Stabilität erleichtert
Wann Self-Hosting ungeeignet ist
- Für frühe Entwicklerphasen und schnelle Prototypen sind Managed Services bequemer
- Großunternehmen fahren unter Umständen besser mit dedizierten Datenbankingenieuren oder mit Cloud-Auslagerung zur Senkung der Personalkosten
- In regulierten Branchen (PCI-DSS, HIPAA usw.) kann die Nutzung zertifizierter Managed-Plattformen vorgeschrieben sein
Wichtige Konfigurationspunkte
- Speichereinstellungen:
shared_buffers, effective_cache_size, work_mem, maintenance_work_mem usw. müssen an die Hardware angepasst werden
- Beispiel:
shared_buffers auf 25 % des RAM, effective_cache_size auf 75 %
- Verbindungsmanagement: Connection Pooling mit
pgbouncer, effizient besonders in Python-asyncio-Umgebungen
- Beispielhafte Grundeinstellungen wie
max_connections = 200, log_connections = on
- Storage-Tuning: In NVMe-SSD-Umgebungen etwa
random_page_cost = 1.1, effective_io_concurrency = 200
- Das verbessert die Geschwindigkeit zufälliger Lesezugriffe und optimiert die Query-Planung
- WAL-Konfiguration: Für Haltbarkeit und Performance etwa
wal_level = replica, max_wal_size = 2GB, checkpoint_completion_target = 0.9
Fazit
- Man muss nicht die gesamte Infrastruktur selbst betreiben, aber Postgres gehört zu den Bereichen, in denen Self-Hosting sinnvoll sein kann
- Wer monatlich mehr als 200 US-Dollar für RDS ausgibt, sollte erwägen, eine nicht kritische Datenbank testweise auf einen eigenen Server zu verlagern
- Künftig dürfte sich die Infrastruktur in Richtung hybrider Modelle aus Managed Services und Self-Hosting entwickeln
- Postgres gilt als starker Kandidat für Self-Hosting mit hoher Kosteneffizienz
Noch keine Kommentare.