Supabase Postgres 14 endet bald: Checkliste vor dem Auto-Upgrade
Der Termin ist nah genug, dass Teams nicht mehr nur über ein zukünftiges Upgrade sprechen sollten. Supabase beendet den Support für Postgres 14 am 1. Juli 2026. Projekte auf einer veralteten Version sollen automatisch auf die aktuell verfügbare Postgres-Version gehoben werden; wenn nicht mehr unterstützte Extensions im Weg stehen, kann das Projekt stattdessen pausiert werden und keinen Traffic bedienen.
Warum jetzt
Upstream ist Postgres 14 laut PostgreSQL-Projekt noch bis zum 12. November 2026 unterstützt. Supabase setzt seine Plattformfrist also früher. Für Managed Services ist das nachvollziehbar, aber für Produktteams heißt es: Nicht die Datenbankversion allein zählt, sondern die Abhängigkeiten rund um Auth, Jobs, Analytics und Integrationen.
Official references to verify before acting: Supabase changelog, Supabase upgrade guide, and PostgreSQL 14 EOL notice.
Was sich ändert
Die Supabase-Dokumentation empfiehlt für viele Projekte ein in-place Upgrade mit `pg_upgrade`. Es ist laut Dokumentation meist schneller als Pause-and-Restore, aber es bleibt ein Downtime-Vorgang. Teams sollten daher vorher testen, ein Wartungsfenster planen und eigene Anwendungstests einplanen.
| Surface | Example | Why it matters |
|---|---|---|
| Version | `select version();` | Do not rely on memory or project age. |
| Extensions | plv8, timescaledb, pgjwt, pg_cron | Extension compatibility decides whether automation is safe. |
| Roles | custom login roles | Passwords for custom roles may need manual handling. |
| Replication | logical replication slots | Slots may need to be recreated after upgrade. |
| Validation | auth, RLS, jobs, webhooks | Application smoke tests catch what platform checks cannot. |
Signal aus der Community
Community-Beiträge zeigen vor allem Verunsicherung bei Extensions, `pg_cron`, Rollen und Replikation. Diese Beiträge ersetzen keine offiziellen Quellen, zeigen aber, wo Praktiker stolpern: nicht beim Klick auf den Upgrade-Button, sondern bei den Randbedingungen danach.
Community migration discussions are useful as narrative signals, but the operational policy should be checked against Supabase’s official changelog and docs.
Auswirkung auf Entwicklung und Betrieb
Prüfen Sie zuerst mit `select version();` die echte Version. Erfassen Sie danach Extensions, Custom Roles, Logical Replication Slots, externe BI/ETL-Verbindungen und kritische User Flows. Führen Sie das Upgrade in Staging oder einer wiederhergestellten Kopie durch und definieren Sie vor Produktion klare Rollback-Kriterien.
Was Teams jetzt tun sollten
Upgrade readiness checklist
✓`select version();` ausführen und dokumentieren.
✓Extensions, `pg_cron`, Custom Roles und Passwörter prüfen.
✓Replication Slots und externe Clients dokumentieren.
✓Upgrade in Staging oder Kopie ausführen.
✓Smoke Tests für Auth, RLS, Webhooks, Jobs und Admin-Flows vorbereiten.
✓Downtime-Fenster, Rollback-Kriterien und Supportweg festlegen.
Für kleine Projekte kann das automatische Upgrade ausreichend sein. Bei produktiven Systemen sollte man es trotzdem nicht blind laufen lassen. Nur das eigene Team weiß, welche Extensions wirklich benutzt werden, welche Passwörter externe Clients erwarten und welche Jobs nach einer Unterbrechung sauber wieder anlaufen müssen.
Risiken und Gegenargumente
Für kleine Projekte kann das automatische Upgrade ausreichend sein. Bei produktiven Systemen sollte man es trotzdem nicht blind laufen lassen. Nur das eigene Team weiß, welche Extensions wirklich benutzt werden, welche Passwörter externe Clients erwarten und welche Jobs nach einer Unterbrechung sauber wieder anlaufen müssen.