Postgres-Hosting-Rechner: Neon vs Supabase vs RDS vs Hetzner

Auto-Suspend: warum Neon bei Dev-Sandboxes praktisch immer gewinnt

Neon ist die einzige große Plattform, die Postgres mit echter Compute-Trennung verkauft. Die DB wird nach ~5 Minuten Inaktivität in einen Suspend-State versetzt, du zahlst dann ausschließlich für Storage. Bei einer Dev-Sandbox, die im Schnitt 2 h/Tag Queries sieht, fallen pro Monat 60 Compute-Stunden an — bei 0,16 USD/Stunde sind das ~10 USD on top zur 19-USD-Base. Macht 27 EUR/Monat für vollwertige Production-grade Postgres mit Branching.

Vergleich Hetzner Managed CCX13 für 20 EUR im Monat: Always-On, keine Compute-Komplexität, kein Branching. Vergleich Supabase Pro für 25 USD: Always-On, 8 GB Storage included, 4 GB Storage extra kostet 0,50 USD/Monat. Bei dauerhafter Last lange gerechnet sind diese günstiger als Neon — aber für eine DB, die nachts und am Wochenende schläft, ist Neon der mit Abstand billigste Path-to-Production.

Die einzige Falle: das erste Query nach Suspend-State braucht ~500 ms Cold-Start. Bei Cron-Workloads, die alle 10 Minuten aufwachen, schläft die DB nie wirklich, und du zahlst 24/7 Compute. In dem Fall ist Hetzner sofort billiger. Faustregel: wenn deine 95p-Idle-Zeit länger als 30 Minuten am Stück ist, gewinnt Neon. Sonst Always-On.

Aurora vs RDS — wann lohnt die Migration

AWS hat zwei Postgres-Modi: RDS ist die klassische Single-Instance-DB mit On-Demand-Sizing in vCPU-Schritten. Aurora ist eine eigene Storage-Engine, die wie eine Postgres-DB aussieht, intern aber ein Multi-Master-Storage-Cluster ist. Aurora Serverless v2 skaliert in 0,5-ACU-Schritten — eine ACU ist grob 1 vCPU / 2 GiB RAM.

Wann lohnt der Switch zu Aurora? Praktisch nur bei zwei Patterns: erstens, wenn dein Traffic stark schwankt (Marketing-Site mit Peak-Tagen, B2B mit Wochenend-Stille). Aurora skaliert in Sekunden hoch und wieder runter — RDS muss du selbst sizen, und ein Resize heißt 10 Minuten Downtime. Zweitens, wenn du Cross-Region-Failover brauchst — Aurora hat eine Global-Database-Fähigkeit, RDS nicht.

Wann lohnt es nicht: konstante Last unter 4 vCPU, kein Multi-Region-Bedarf. Da ist RDS db.t4g.medium für 60 USD/Monat ungefähr 30 % günstiger als die equivalent 2-ACU-Aurora-Baseline, und du verlierst weniger Geld an die ACU-Step-Aufrundung. Aurora Serverless hat außerdem einen versteckten Pain-Point: kein eingebauter Connection-Pooler. Du brauchst RDS Proxy zusätzlich (~$15/Monat pro Instanz), oder dein Lambda-Spike killt die ACUs.

Hetzner Managed Postgres: was es noch nicht kann

Hetzner hat 2024 sein Managed-Postgres-Angebot offiziell launched. Stand Mai 2026 ist es das günstigste deutsche Hosting auf dem Markt — 20 EUR im Monat für 2 vCPU / 4 GiB / 80 GB SSD inkl. Backups. Wer sich nur den Listenpreis ansieht, denkt: kann das wirklich sein. Es kann — wenn du die Features nicht brauchst, die Hetzner nicht hat:

• Multi-AZ-Failover mit RTO < 60s. Hetzner hat Read-Replicas, aber kein automatisches Promotion-Failover. Bei einem Hardware-Ausfall musst du selbst auf das Replica umschalten — für PSD2-Banking oder Healthcare-SaaS mit SLA ist das untragbar. RDS Multi-AZ macht das in ~30 Sekunden automatisch.
• Eingebauter Connection-Pooler. Bei RDS Proxy oder Supabase Pooler bekommst du eine zweite Endpoint-URL geliefert. Bei Hetzner musst du selbst einen PgBouncer-Container daneben hochziehen oder pg-pool-2 in einer separaten VM betreiben.
• Granulare PITR. Hetzner bietet 7 Tage tägliche Snapshots. RDS und Aurora gehen bis zu 35 Tage mit Sekunden-genauen Restore-Points. Für regulatorische Anforderungen (BaFin, GxP) ist das ein Unterschied.
• Cross-Region-Replikation als Service. Wenn du eine echte EU-Multi-Region-Setup brauchst — Hetzner Cloud hat zwar mehrere Locations (Falkenstein, Nürnberg, Helsinki), aber managed Cross-Region-Replikation musst du selbst skripten.

Für 95 % der Mid-Market-SaaS-Apps mit europäischen Kunden ist all das irrelevant. Die kleinen Limits werden erst dann ein Problem, wenn du tatsächlich an die Grenzen kommst. Bis dahin sparst du 60-80 % gegenüber der RDS- oder Cloud-SQL-Rechnung — und Hetzner sitzt in Deutschland, was für DSGVO-affine Kunden ein eigenständiger Verkaufsfaktor ist.

Connection-Pooling: PgBouncer vs Provider-built-in

Wer eine serverless App auf Vercel oder AWS Lambda fährt, hat ein Problem: jeder Lambda-Invocation öffnet eine eigene DB-Connection, und Postgres ist nach ~100 Connections am Anschlag. Die Standardlösung heißt PgBouncer — ein Pool, der zwischen App und DB sitzt und tausende Client-Connections auf wenige DB-Connections multiplext.

Bei Neon und Supabase ist PgBouncer eingebaut. Du kriegst zwei URLs: eine direkte und eine Pooler-URL. Bei Lambda nimmst du die Pooler-URL, fertig. Bei RDS musst du RDS Proxy aktivieren — kostet $0,015 pro vCPU pro Stunde, also ungefähr $15-30 pro Monat extra. Bei Aurora Serverless v2 ist der eingebaute Proxy ebenfalls extra. Bei Hetzner und DigitalOcean musst du PgBouncer selbst hosten — ein Container daneben, der ist nicht schwierig, aber ein zusätzlicher Single-Point-of-Failure.

Der versteckte Cost-Killer: PgBouncer kennt zwei Modi — Transaction-Pooling und Session-Pooling. Transaction-Pooling ist effizienter, bricht aber Prepared Statements, Advisory Locks und LISTEN/NOTIFY. Wer mit Prisma oder Hasura arbeitet, muss prepared_statements explizit ausschalten. Wenn du das vergisst, sieht alles in Dev fein aus und kollidiert in Production.

Häufige Fragen