Los, hoste Postgres selbst

 (pierce.dev)
5 Punkte von GN⁺ 2025-12-21 | 4 Kommentare | Auf WhatsApp teilen
  • 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

Verwandte Beiträge

4 Kommentare

 
yangeok 2025-12-23

Da der Speicher ebenfalls 11 Neunen garantiert, ist der Betrieb natürlich nicht schwierig, wenn man die Cloud nutzt – genau deshalb nutzt man ja die Cloud, haha.
 
kaydash 2025-12-22

In der Praxis ist der Betrieb eines 3-Node-Clusters wahrscheinlich gar nicht so einfach.
 
GN⁺ 2025-12-21
Hacker-News-Kommentare

  • Ich sehe Self-Hosting als eine Frage der Verantwortung
    Ich hoste einige SaaS-Produkte selbst; das ist deutlich günstiger als AWS und die Performance ist auch viel besser.
    Bei Kundenprojekten überzeuge ich die Kunden allerdings davon, die AWS-Kosten zu tragen. So kann man die Verantwortung für die Verfügbarkeit der Hardware auf jemand anderen abwälzen.
    Wenn das Budget knapp ist, sind die Kosten für RDS belastend. Einen 3-Knoten-Galera-Cluster bei Hetzner für ein paar Dollar zu betreiben ist viel wirtschaftlicher.
    Allerdings haben auch Managed Services wie Cloudflare oder SQS gelegentlich Ausfälle. Perfekte Stabilität gibt es letztlich nirgends.

    • Ich fragte: „Warum wechseln Sie von NoNameCMS zu Salesforce?“ Die Antwort war: „Wenn Salesforce ausfällt, steht es im WSJ.“ Das ist ein sehr realistischer Grund für Schuldabwälzung.
    • Aus Sicht der Kunden des Kunden hilft die Aussage „Ikea und Disney waren auch down“ überhaupt nicht. Am Ende zählt nur, dass der eigene Dienst stillsteht.
    • Es gibt AWS Serverless PG, daher gibt es keinen besonderen Grund, das selbst zu betreiben. Bei wenig Traffic ist es fast kostenlos und bei Sicherheit, Backups und Integration deutlich besser.
      AWS Aurora Serverless
    • Man kann auch einen Mittelweg gehen und nur bis auf VM-Ebene auslagern und den Rest selbst verwalten. Das hängt vom operativen Overhead des Tech-Stacks ab.
    • Ich habe 20 Jahre lang self-hosted SQL bei zahllosen Kunden betrieben und nie erlebt, dass ein SQL-Server ausgefallen ist.
      Cloud-SQL hat dagegen eher eine komplizierte Kostenstruktur, und wenn man Backups einmal eingerichtet hat, ist das Thema erledigt.

  • Ich stimme der Behauptung nicht zu, dass Self-Hosting für die meisten die richtige Wahl ist.
    Ich halte es eher dann für sinnvoll, wenn das Budget sehr knapp ist oder wenn das Unternehmen groß genug für dedizierte Engineers ist.
    Für kleine Firmen ist es realistischer, es der Cloud zu überlassen. Nach dem Setup reichen rechnerisch 30 bis 120 Minuten Wartung pro Monat.

    • Die meisten Unternehmen stellen selbst mit Cloud weiterhin Infrastruktur-Engineers ein. Die Behauptung „Cloud senkt Personalkosten“ ist falsch.
      PaaS wie Heroku oder Render können auch normale Entwickler bedienen, sind aber viel teurer.
      Wenn die Wiederherstellung der Anwendung am Ende nicht automatisiert ist, wird man um 3 Uhr morgens trotzdem geweckt.
    • Die meisten Dienste brauchen keine Hochverfügbarkeit. Wenn etwas am Samstag ausfällt, reicht es, es am Montag zu reparieren.
      Für ein internes Tool dauert es nur fünf Minuten, in Docker noch ein Postgres hinzuzufügen.
    • Auch Cloud verursacht etwa 1–2 Stunden Verwaltungsaufwand pro Monat. Der Unterschied zu Self-Hosting ist nicht groß.
    • Mit RDS hat man sogar weniger Sichtbarkeit und Kontrolle, wodurch Debugging schwieriger wird.
    • Es geht nicht um Effizienz, sondern darum, wer beschimpft wird, wenn etwas schiefläuft. Mit Cloud lässt sich die Verantwortung leichter weiterreichen.

  • Die Definition von „Managed Database“ ist verwirrend.
    Für mich gehören dazu mindestens automatische Backups, Index-Optimierung, Multi-Datacenter-Failover, Point-in-Time-Recovery, Slow-Query-Analyse und Speicherprognosen.
    Wenn all das gegen eine Monatsgebühr angeboten wird, verliert die Self-Hosting-Debatte an Bedeutung.

    • Das Problem ist, dass man Fachpersonal einstellen muss. Wenn die für Postgres zuständige Person Urlaub hat, entsteht ein Bus-Faktor-Problem.
      Am Ende stellt man zwei Leute ein, und weil es zu ruhig wird, versuchen sie unnötige Verbesserungen und verschwenden dabei sechs Monate.
    • Der Grund für Self-Hosting ist letztlich Latenz. Backups und Analyse sind Standard, aber am schnellsten ist es, wenn man es selbst aufbaut.
    • Wenn das Setup gut gemacht ist, lassen sich auch Backups oder Multi-Region-Failover automatisieren.
    • Ich hoste nur Dienste selbst, für die mich um 3 Uhr morgens niemand anruft. Für Logs oder interne Analysen ist das okay, aber niemals für die DB.
    • Yugabyte Open Source deckt die meisten dieser Funktionen ab.

  • Managed DBs sind im Vergleich zu VPS viel zu teuer.
    Ich hatte einen Aufpreis für Bequemlichkeit erwartet, tatsächlich sind sie aber um ein Vielfaches teurer. Deshalb nutze ich sie nur für große Projekte.

    • Man bringt einen dazu zu glauben, dass man es selbst nicht kann, und erhöht in der Zwischenzeit ständig die Preise. Weil einem die Fähigkeit zum Umzug fehlt, entsteht Abhängigkeit.

  • Der im Artikel erwähnte Teil zu Hochverfügbarkeit (HA) ist unzureichend. Mit WAL-Einstellungen allein ist es nicht erklärt. Replikation ist teuer.

  • Ich verstehe nicht, warum Postgres auf HN so überbewertet wird.
    Es gibt keinen einfachen Weg, wie bei MongoDB einen HA-Cluster mit automatischem Failover aufzusetzen. Mich würde interessieren, wie das in produktiven Systemen gelöst wird.

    • Auch die PostgreSQL-Community ist sich dieses Problems bewusst. Man beneidet MongoDB um die Stabilität der eingebauten Replikation.
      Relevante Diskussion: PostgreSQL-Mailingliste
    • Wenn man Kubernetes nutzt, ist CloudNativePG faktisch die Standardlösung für HA.
    • Das SQL-Lager ist statt an echter HA eher an schnelle Recovery (Disaster Recovery) gewöhnt.
      In der Praxis werden alle Verbindungen getrennt, Caches zurückgesetzt, und bei Upgrades ist eine Unterbrechung des Dienstes unvermeidlich.
      Nur Oracle RAC ist eine Ausnahme; PostgreSQL ist nicht so aufgebaut. YugabyteDB ist noch am ehesten eine Alternative.
      Die meisten Apps akzeptieren einige Stunden Downtime. Nur große Unternehmen können sich die komplexe Automatisierung leisten.
    • Die gebräuchlichste Methode ist die Nutzung von Patroni. Wenn es einfach sein soll, dann Autobase.
      In Kubernetes-Umgebungen ist auch CloudNativePG gut.
      pg_auto_failover ist simpel, hat aber Einschränkungen.
    • Tatsächlich brauchen die meisten Unternehmen solch komplexe HA gar nicht. Das Kosten-Nutzen-Verhältnis ist gering.

  • Wenn man sich Autobase ansieht, automatisiert es beim Self-Hosting viele der nötigen Aufgaben.

    • Ich habe das README überflogen; Connection Pooling scheint nicht zum Umfang zu gehören.
    • Ich frage mich, ob es sich auch gut mit anderen self-hosted PaaS integrieren lässt. Es scheint in Form von Docker-Containern zu laufen.
    • Tolles Projekt, danke dafür.

  • Ich nutze Postgres seit 15 Jahren immer self-hosted und hatte fast nie Probleme.
    Die einzige Sorge war, PG-Versionsmigrationen passend zu ORM-Upgrades durchführen zu müssen. Mit sorgfältiger Systemadministration ließ sich das lösen.

  • Ich habe auf Fly.io nicht verwaltetes Postgres selbst betrieben und es war wirklich mühsam.
    Nodes starben häufig, sodass ich mit repmgr manuell wiederherstellen musste, und schließlich habe ich die Abläufe im internen Wiki dokumentiert.
    Der Sinn des Clusters ist Hochverfügbarkeit – ich habe nie verstanden, warum Zombie-Primaries nicht automatisch behandelt werden.
    Am Ende bin ich zu Managed Postgres gewechselt, und es ist wirklich angenehm, wenn sich im Störungsfall jemand anderes darum kümmert.

    • Inzwischen nutze ich das Managed Postgres von Fly.

  • Viele Kommentare in diesem Thread ignorieren reale Faktoren wie Größe, Workload, Personal, Zeit, Geschäftsphase und Skalierungsanforderungen.
    Self-Hosting kann passend sein oder auch nicht, aber die Diskussion ist viel zu simpel.

    • Engineers berücksichtigen solche Faktoren fast nie und neigen dazu, die teuerste Lösung zu wählen, die der Chef noch genehmigt.
 
sinbumu 2025-12-22

Für Entwickler ist wahrscheinlich auch wichtig, ob solche Faktoren anerkannt werden, wenn man so etwas selbst hostet. Selbst wenn die Cloud-Kosten höher ausfallen: Wenn die Kosteneinsparung durch Self-Hosting nicht anerkannt wird, ist es am Ende wohl entspannter, einfach einen Cloud-Service zu nutzen und den Bereich, den man selbst abdecken muss, zu verkleinern.