/ Artikel

Datenbank umbenennen und Owner wechseln

Wie man in PostgreSQL eine Datenbank umbenennt mit ALTER DATABASE … RENAME TO und den Besitzer mit ALTER DATABASE … OWNER TO wechselt — inklusive Voraussetzungen, Auswirkungen auf bestehende Sessions und Connection-Strings.

Eine bestehende Datenbank umbenennen oder den Owner wechseln klingt trivial — und ist es technisch auch. Die Reibung entsteht eher außerhalb der Datenbank: Connection-Strings in Apps, Backup-Skripte, hardcodierte DB-Namen in Code-Reviews. Dieser Artikel zeigt die Befehle und worauf du daneben achten solltest.

01 · Abschnitt

Datenbank umbenennen

SQL ALTER DATABASE … RENAME TO

ALTER DATABASE myapp RENAME TO myapp_v2;

Voraussetzungen:

Du musst Owner der DB sein oder Superuser.
Es darf keine offene Connection auf die DB geben — auch deine eigene nicht. Daher: vorher in eine andere Datenbank wechseln.

Bash Praktisches Vorgehen

# Verbinde dich nicht mit myapp, sondern mit postgres:
psql -d postgres

SQL

-- Andere Connections beenden (falls vorhanden):
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE datname = 'myapp';

-- Neue Connections vorerst blockieren:
ALTER DATABASE myapp ALLOW_CONNECTIONS = false;

-- Umbenennen:
ALTER DATABASE myapp RENAME TO myapp_v2;

-- Wieder oeffnen:
ALTER DATABASE myapp_v2 ALLOW_CONNECTIONS = true;

ALLOW_CONNECTIONS = false (PG 9.5+) ist ein eleganter Hebel für Migrationen: keine neuen Verbindungen werden zugelassen, bis du wieder freigibst. So kann zwischen den Schritten kein Service einen Socket öffnen, der dann beim Rename platzt.

02 · Abschnitt

Owner wechseln

SQL ALTER DATABASE … OWNER TO

ALTER DATABASE myapp OWNER TO new_owner;

Voraussetzungen:

Du musst aktueller Owner sein oder Superuser.
Du musst Mitglied der Ziel-Rolle sein (sonst: „permission denied”).
Du brauchst CREATEDB-Recht — Postgres prüft das, bevor es den Wechsel vollzieht.

Der Owner-Wechsel ist nicht rekursiv. Nur die Datenbank selbst wechselt — die Tabellen, Schemas und Funktionen darin bleiben bei ihrem jeweiligen Owner. Wenn du die auch übertragen willst, brauchst du REASSIGN OWNED:

SQL

\c myapp
REASSIGN OWNED BY old_owner TO new_owner;

Das verschiebt alle Objekte in der aktuellen Datenbank, die old_owner gehörten, an new_owner. Mehr dazu im Artikel Ownership und Besitz.

03 · Abschnitt

Was ALTER DATABASE alles kann

Neben Rename und Owner gibt’s eine handvoll weiterer Tweaks pro DB:

Befehl	Wirkung
`ALTER DATABASE myapp SET search_path = …`	Setzt einen Default-search_path für alle Verbindungen zu dieser DB
`ALTER DATABASE myapp SET timezone = 'UTC'`	Default-Zeitzone
`ALTER DATABASE myapp SET log_min_duration_statement = 100`	Slow-Query-Log nur für diese DB aktivieren
`ALTER DATABASE myapp CONNECTION LIMIT 100`	Maximal gleichzeitige Verbindungen
`ALTER DATABASE myapp ALLOW_CONNECTIONS = false`	Verbindungen blockieren
`ALTER DATABASE myapp IS_TEMPLATE = true`	Als Template für CREATE DATABASE markieren
`ALTER DATABASE myapp SET TABLESPACE fast_ssd`	In anderen Tablespace verschieben

ALTER DATABASE … SET … greift erst bei der nächsten Connection — bestehende Sessions sind unverändert.

04 · Abschnitt

Auswirkungen außerhalb der DB

Ein Rename oder Owner-Wechsel ist innerhalb der DB schnell. Außerhalb wird’s stressig:

Connection-Strings in Anwendungen, .env-Dateien, Kubernetes-Secrets, Service-Mesh-Routing — alle hardcoden den DB-Namen. Vor dem Rename suchen, wo überall myapp steht, und einen Plan haben.
Backup-Skripte referenzieren oft den DB-Namen. pg_dump -d myapp muss zu pg_dump -d myapp_v2 werden — und Backup-Filenames wandern entsprechend mit.
Monitoring/Dashboards. Datadog, Grafana, Prometheus-Targets — überall steht der DB-Name in Labels.
Replikations-Setups. Logische Replikation referenziert DB-Namen in Subscriptions; physische Replikation ist davon unabhängig.

Faustregel: erst alle externen Stellen identifizieren, dann renamen. Die zwei Sekunden für ALTER DATABASE … RENAME TO … sind der einfachste Schritt.

05 · Abschnitt

Cluster-weiter Owner-Wechsel

Wenn ein User abgeht und seine Daten in mehreren Datenbanken besitzt, ist das ein größeres Aufräumprojekt. Pro Datenbank:

SQL In jeder Datenbank, die der alte User beruehrte

\c db1
REASSIGN OWNED BY old_user TO new_owner;
DROP OWNED BY old_user;

\c db2
REASSIGN OWNED BY old_user TO new_owner;
DROP OWNED BY old_user;

-- ... fuer alle betroffenen DBs ...

\c postgres
DROP ROLE old_user;

Welche DBs betroffen sind, lässt sich aus pg_database plus dem Wissen, wo der User beruflich tätig war, ableiten. Pragmatisch: einfach alle DBs durchgehen — REASSIGN OWNED ist ein No-op, wenn der User dort nichts besitzt.

06 · Abschnitt

Häufige Stolperfallen

ALTER DATABASE RENAME TO geht nicht von INNERHALB der DB.

Du kannst eine Datenbank nicht umbenennen, in der du verbunden bist — Postgres lehnt mit „cannot ALTER DATABASE currently in use” ab. Vorher in eine andere Datenbank wechseln (\c postgres ist der Standard-Trick).

Bestehende Connections bleiben nach Rename verbunden.

Wer beim Rename in myapp verbunden ist (auf einer anderen Connection), bleibt verbunden — Postgres aktualisiert intern die Referenz. Aber wenn die Verbindung mal abbricht, kann der Client sich mit dem alten Namen nicht mehr verbinden. Daher: Apps neu deployen mit dem neuen Namen, sobald der Rename durch ist.

Owner-Wechsel braucht Mitgliedschaft in der Ziel-Rolle.

Der typische Fehler: ALTER DATABASE myapp OWNER TO new_owner schlägt mit „must be member of role” fehl. Lösung: erst GRANT new_owner TO postgres; (oder zur ausführenden Rolle), dann den OWNER-Wechsel, dann ggf. das GRANT wieder zurückziehen.

Owner-Wechsel ist nicht rekursiv.

ALTER DATABASE myapp OWNER TO new_owner ändert NUR den Database-Owner-Eintrag. Tabellen, Schemas, Funktionen behalten ihren alten Owner. Wer das nicht weiß, wundert sich später, dass der „neue Owner” Tabellen nicht droppen darf — er ist nicht deren Owner. Lösung: REASSIGN OWNED BY old_owner TO new_owner in der Datenbank.

ALLOW_CONNECTIONS = false hilft beim Maintenance-Fenster.

Eine sehr unterschätzte Eigenschaft. Vor riskanten Migrations: DB für neue Connections sperren, alle bestehenden beenden, Migration laufen lassen, wieder öffnen. Während des Fensters bekommen Apps einen sauberen „cannot connect”-Fehler statt halb laufender Operationen.

Der Postgres-User selbst kann nicht alle DBs droppen.

postgres ist Cluster-Superuser — kann technisch alles. Aber er kann eine DB nicht droppen, in der er gerade verbunden ist. Das gilt selbst für Superuser. Klingt selbstverständlich, kostet aber im Eifer des Gefechts gerne mal 10 Sekunden Verwirrung.

07 · Abschnitt

Weiterführende Ressourcen

Externe Quellen

/ Weiter

Zurück zu Server-Administration

Zur Übersicht