Einen Anbieter für Managed PostgreSQL für die Produktion wählen

Die Wahl des Anbieters für Managed PostgreSQL wirkt sich über Jahre auf Datenhoheit, Betriebslast, Notfallvorsorge und Gesamtkosten aus. Diese Seite vergleicht sechs Optionen, die Schweizer Organisationen heute offenstehen: den Eigenbetrieb, die drei grossen Hyperscaler, Aiven und VSHN Managed PostgreSQL.

Der Vergleich behandelt das Community-PostgreSQL. Wenn dein Projekt Oracle-Kompatibilität oder die EDB-Werkzeuge für Unternehmen braucht, findest du das auf enterprisedb.ch.

Vergleich auf einen Blick

Die Preise der Cloud-Anbieter sind On-Demand-Listenpreise in USD für die genannte Konfiguration und Region, abgelesen am 15. September 2026 in den Preislisten der Anbieter. Speicher, Backups und Datentransfer kommen dazu, ausser dem Speicher, der in einem Aiven-Plan enthalten ist.

Beratung anfragen

PostgreSQL im Eigenbetrieb

PostgreSQL auf eigenen VMs oder im eigenen Kubernetes-Cluster zu betreiben gibt volle Kontrolle über Konfiguration, Standort und Zugriff.

Stärken: vollständige Datenhoheit, keine Gebühren pro Dienst, alle Erweiterungen verfügbar, jede PostgreSQL-Version.

Grenzen: die Betriebslast ist erheblich. Produktives PostgreSQL verlangt Monitoring rund um die Uhr, automatisierte Backups mit Wiederherstellungstests, den Aufbau der Hochverfügbarkeit (Patroni, repmgr oder CloudNativePG), Sicherheitspatches und die Steuerung der Wechsel von Hauptversionen. Ein eigener PostgreSQL-DBA ist ein volles Salär, und eine einzelne Person deckt keinen Betrieb rund um die Uhr ab. Kleinere Teams schieben Upgrades häufig auf und lassen Wiederherstellungstests aus. Beides erzeugt ein Risiko, das erst im Störungsfall sichtbar wird.

Passt, wenn: deine Organisation ein eigenes Datenbankteam mit PostgreSQL-Wissen hat und besondere Anpassungen braucht, die kein verwalteter Dienst abdeckt.

Amazon RDS für PostgreSQL

Amazon RDS ist der Marktführer bei verwaltetem PostgreSQL. Der Dienst übernimmt Bereitstellung, Patching, Backups und Failover innerhalb des AWS-Ökosystems.

Stärken: ausgereifter Dienst mit breitem Funktionsumfang (Read Replicas, Performance Insights, Point-in-Time Recovery), Region Zürich (eu-central-2) seit 2022 verfügbar, enge Verzahnung mit den AWS-Diensten.

Grenzen: Amazon ist ein US-Unternehmen und untersteht dem CLOUD Act. Auch mit einer Region in Zürich können US-Behörden Zugriff auf die Daten erzwingen, ohne Schweizer Gerichtsverfahren. RDS läuft ausschliesslich auf AWS-Infrastruktur, also nicht auf Cloudscale, Exoscale oder in deinem eigenen Rechenzentrum. Dazu kommt eine starke Bindung an AWS über IAM, VPC und CloudWatch. Rechenleistung, Speicher, IOPS und Backups werden getrennt verrechnet, was die Kosten schwer vorhersehbar macht.

Passt, wenn: dein Team ohnehin auf AWS gesetzt hat und die Abwägung zum US-Recht bewusst annimmt.

Unsere Souveränitätsbewertung für PostgreSQL vergleicht die rechtliche Seite im Detail.

Google Cloud SQL für PostgreSQL

Cloud SQL ist der verwaltete Dienst für relationale Datenbanken von Google. Die Region Zürich (europe-west6) hält Rechenleistung und Speicher in der Schweiz.

Stärken: Region Zürich mit geringer Latenz aus Schweizer Infrastruktur, automatisierte Backups und Point-in-Time Recovery, konkurrenzfähiger Preis für kleinere Instanzen.

Grenzen: Google untersteht dem CLOUD Act, unabhängig davon, wo die Daten liegen. Cloud SQL läuft ausschliesslich auf Google-Infrastruktur. Dazu kommt die Bindung an GCP bei Networking, Identität und Monitoring. Wechsel der Hauptversion verlangen Ausfallzeit oder eine manuelle Migration. Die IOPS hängen an der Plattengrösse, was das Performance-Tuning einschränkt.

Passt, wenn: dein Team in Google Cloud investiert ist und eine Datenbank in Zürich braucht.

Unsere Souveränitätsbewertung für PostgreSQL vergleicht die rechtliche Seite im Detail.

Azure Database for PostgreSQL

Azure Database ist das Angebot von Microsoft für verwaltetes PostgreSQL, verfügbar als Flexible Server mit zonenredundanter Hochverfügbarkeit.

Stärken: zonenredundante Hochverfügbarkeit mit 99,99 Prozent SLA, EU-Regionen verfügbar, automatisierte Backups und Point-in-Time Recovery, Verzahnung mit IAM und Networking von Azure.

Grenzen: Microsoft untersteht dem CLOUD Act. Dazu kommt die Bindung an Azure bei Networking, Monitoring und Zugriffssteuerung.

Passt, wenn: dein Team ohnehin im Azure-Ökosystem arbeitet und verwaltetes PostgreSQL braucht.

Unsere Souveränitätsbewertung für PostgreSQL vergleicht die rechtliche Seite im Detail.

Aiven für PostgreSQL

Aiven ist ein finnisches Unternehmen und bietet verwaltete Datenbanken über mehrere Clouds an. PostgreSQL läuft dabei auf AWS, GCP oder Azure in der Region deiner Wahl.

Stärken: Firmensitz in der EU (Helsinki), Multi-Cloud über AWS, GCP und Azure, gute Entwicklererfahrung mit CLI-Werkzeugen und Terraform-Provider.

Grenzen: Aiven läuft auch in EU-Regionen auf US-Hyperscalern. Über die darunterliegende Infrastruktur bleibt die Berührung mit dem CLOUD Act bestehen. Eine Option auf Infrastruktur in Schweizer Besitz gibt es nicht. Das SLA von 99,99 Prozent gilt für die Stufen Startup, Business und Premium, nicht nur für die teuerste. Eine eigene Schweizer Region fehlt, am nächsten liegt üblicherweise die Region Frankfurt oder Zürich des darunterliegenden Hyperscalers.

Passt, wenn: du einen einzigen Anbieter für verwaltete Datenbanken über mehrere Hyperscaler willst und dir der EU-Firmensitz wichtiger ist als Hosting in der Schweiz.

VSHN Managed PostgreSQL (AppCat)

VSHN betreibt PostgreSQL auf der Infrastruktur deiner Wahl über AppCat, mit dem quelloffenen Operator CloudNativePG auf Kubernetes.

Stärken:

• Schweizer Firma, Schweizer Zuständigkeit. VSHN hat den Sitz in Zürich. Über die Betriebsschicht besteht keine Berührung mit dem CLOUD Act.
• Infrastruktur nach deiner Wahl. Cloudscale, Exoscale, eigenes Rechenzentrum oder acht Anbieter über Servala.
• Vollständig quelloffen. CloudNativePG ist ein Projekt der Linux Foundation, ohne proprietäre Dienstschicht.
• PostgreSQL 14 bis 18, das aktuelle Release eingeschlossen. Eine Version fällt weg, sobald das PostgreSQL-Projekt sie nicht mehr unterstützt: 13 ging mit seinem Support-Ende im November 2025.
• Automatisierte tägliche Backups mit sechs aufbewahrten Ständen (einstellbar).
• SLA bis 99,99 Prozent, mit Gutschriften bei Unterschreitung.
• Nach ISO 27001 zertifizierter Betrieb.
• Selbstbedienung über die Kubernetes-API oder über Servala.

Preise:

Die Preise gelten für den Datenbankdienst. Rechenleistung, Arbeitsspeicher und Speicherplatz kommen dazu. VSHN kauft sie für dich ein, ausser du willst dein eigenes Cloud-Abo behalten: dann verrechnet dir der Anbieter diesen Teil.

Passt, wenn: Schweizer Zuständigkeit gefordert ist, du planbare Preise willst oder dein Team den Datenbankbetrieb rund um die Uhr nicht dauerhaft tragen kann.

Logische Replikation, und was ihre Aktivierung kostet

Wer in ein Data Warehouse repliziert, Change Data Capture betreibt oder mit Debezium oder PowerSync synchronisiert, entscheidet die engere Auswahl an dieser Zeile, noch bevor der Preis eine Rolle spielt.

Bei uns ist sie bereits aktiv. wal_level steht auf logical, weil CloudNativePG das so vorgibt. Die Rolle in deinem Connection Secret ist der postgres-Superuser, also funktionieren pg_create_logical_replication_slot, CREATE PUBLICATION und das Plugin pgoutput ohne weitere Rechte, ohne Parameteränderung, ohne Neustart und ohne Support-Ticket. Du bekommst 32 Replication Slots.

CloudNativePG liefert enableSuperuserAccess: false aus, und wer diesen Standardwert kennt, misstraut einem blossen Häkchen zu Recht. Wir überschreiben ihn auf true. Mehr ist es nicht, und du siehst die Rolle vom ersten Tag an selbst im Secret.

Drei Einschränkungen, die anderswo in einer Fussnote verschwinden:

• Slots überleben ein Failover erst ab PostgreSQL 17, und auf einer einzelnen Instanz gar nicht. Rechne damit, die Subscription neu anzulegen, wenn du ohne Replica fährst.
• Ein Major-Upgrade läuft über pg_upgrade, und das verwirft Replication Slots. Das ist Verhalten von PostgreSQL und nicht von uns, bedeutet aber: ein Upgrade ist für deinen Consumer eine geplante Unterbrechung.
• Unser Alerting überwacht den Zustand der Slots nicht. Ein inaktiver Slot hält Write-Ahead-Log unbegrenzt zurück, weil max_slot_wal_keep_size auf dem PostgreSQL-Standardwert -1 steht, und füllt irgendwann die Platte. Wer einen Slot anlegt, überwacht ihn. Das ist der Punkt, der Geld kostet, wenn niemand hinschaut.

Was die anderen verlangen. Logische Replikation kann jeder von ihnen. Der Unterschied liegt im Aufwand: Amazon RDS will rds.logical_replication auf 1, ein statischer Parameter und damit ein Neustart; Cloud SQL will das Flag cloudsql.logical_decoding; Azure will wal_level auf logical. Aiven gibt gar kein Superuser-Konto heraus und liefert dafür aiven_extras mit, damit Publish und Subscribe auch ohne funktioniert.

Eigene Parameter laufen bei uns über pgSettings. Fünfzehn sind gesperrt, und ein gesperrter Parameter wird beim Anwenden abgelehnt statt später stillschweigend überschrieben. Du merkst es also sofort und kannst nachfragen.

Welche Option passt?

Den Eigenbetrieb wählst du, wenn du eigene DBA-Kapazität hast und volle Kontrolle über die Konfiguration brauchst.

Amazon RDS oder Cloud SQL wählst du, wenn du dich ohnehin auf dieses Hyperscaler-Ökosystem festgelegt hast und die US-Zuständigkeit vertretbar ist.

Azure Database wählst du, wenn deine Organisation im Azure-Ökosystem arbeitet und ein zonenredundantes SLA von 99,99 Prozent zum Preis von Microsoft gefordert ist.

Aiven wählst du, wenn du einen einzigen Anbieter für verwaltete Datenbanken über AWS, GCP und Azure brauchst, ohne zu einem spezialisierten Betreiber zu wechseln.

VSHN Managed PostgreSQL wählst du, wenn deine Daten unter Schweizer Zuständigkeit bleiben müssen, du planbare Preise in CHF willst oder dein Team den PostgreSQL-Betrieb abgeben möchte.

Nächste Schritte

Bereit, dein aktuelles Setup mit PostgreSQL aus Schweizer Betrieb zu vergleichen? Buch eine Beratung. Wir sehen deine Anforderungen an die Datenbank durch und empfehlen den passenden Weg.