Unter macOS gibt es drei verbreitete Wege, PostgreSQL für die lokale Entwicklung einzurichten: Postgres.app als komplett gepacktes GUI-Bundle, Homebrew als klassischer Package-Manager und Docker für reproduzierbare Setups, die nahe an die Produktion herankommen. Welche Variante passt, hängt vor allem davon ab, wie viel Kontrolle du haben willst und ob Postgres ständig oder nur projektweise laufen soll.

01 · Abschnitt

Variante 1 — Postgres.app (empfohlen für Einsteiger)

Postgres.app ist eine native macOS-App, die einen vollständigen Postgres-Server mit allen verbreiteten Extensions (PostGIS, pgvector, plv8, …) bündelt. Du lädst die App, ziehst sie in /Applications, startest sie — fertig. Im Menüleisten-Icon kannst du Server starten/stoppen und mehrere Versionen parallel laufen lassen.

Ein paar Mal manuell setzen muss man trotzdem:

Bash psql in den PATH aufnehmen 
# In ~/.zshrc bzw. ~/.bash_profile ergaenzen:
export PATH="/Applications/Postgres.app/Contents/Versions/latest/bin:$PATH"

Damit findet die Shell psql, pg_dump, createdb etc. Postgres.app legt das Daten-Verzeichnis unter ~/Library/Application Support/Postgres/var-<version> ab.

Wann sinnvoll: lokale Entwicklung, wenn der Server „immer da sein soll“, ohne dass man Services konfiguriert. Postgres.app fragt beim Login, ob es automatisch starten soll.

02 · Abschnitt

Variante 2 — Homebrew

Wer ohnehin mit Homebrew arbeitet, installiert Postgres direkt über die Formula:

Bash Postgres ueber Homebrew installieren 
brew update
brew install postgresql@18

Homebrew installiert versions-spezifisch (postgresql@16, postgresql@17, postgresql@18). Die Service-Steuerung läuft über brew services:

Bash Service starten / stoppen 
brew services start  postgresql@18
brew services stop   postgresql@18
brew services restart postgresql@18

Die Daten liegen je nach Apple-Silicon/Intel unter /opt/homebrew/var/postgresql@18/ (Apple Silicon) bzw. /usr/local/var/postgresql@18/ (Intel). Verbinden ohne weitere Argumente klappt mit dem System-User:

Bash 
psql postgres

Wann sinnvoll: wenn dein restliches Setup ohnehin auf Homebrew läuft und du die Postgres-Version mit brew upgrade mitziehen willst.

03 · Abschnitt

Variante 3 — Docker (für produktionsnahe Setups)

Wenn du jeden Tag mit dem Postgres-Server arbeitest, der auch in Produktion läuft, oder zwischen mehreren Projekten mit unterschiedlichen Versionen springst, ist Docker oft die saubersten Variante:

Bash Postgres im Docker starten 
docker run --name pg18 \
  -e POSTGRES_PASSWORD=secret \
  -p 5432:5432 \
  -v pg18_data:/var/lib/postgresql/data \
  -d postgres:18

Vorteile: definierte Version pro Projekt, einfaches Wegwerfen und Neuanlegen, kein systemweiter Service. Nachteile: kleiner Performance-Overhead (vor allem bei I/O auf macOS Docker Desktop) und die Notwendigkeit, Daten-Volumes bewusst zu verwalten.

Ausführlicher behandelt das der Artikel PostgreSQL im Docker einrichten.

04 · Abschnitt

Welche Variante sollte ich nehmen?

SituationEmpfehlung
Erste Postgres-Installation, Lernen, kleine ProjektePostgres.app — null Konfigurationsaufwand, GUI, Extensions inklusive
Bestehendes Homebrew-Setup, alles über CLIHomebrew
Mehrere Projekte mit unterschiedlichen PG-VersionenDocker, ein Container pro Projekt
Postgres soll möglichst nahe am Produktionssystem laufenDocker mit der gleichen Image-Version wie produktiv
Dauerhafter Single-Server-Betrieb auf eigenem MacPostgres.app oder Homebrew — Docker Desktop nicht im Idle laufen lassen

Du kannst die Varianten auch mischen — z. B. Postgres.app als „Standard-Datenbank für alle kleinen Skripte“ plus Docker pro Projekt. Aber: nur eine davon sollte gleichzeitig auf Port 5432 hören. Wer Postgres.app und Homebrew-Postgres parallel laufen lässt, sollte einer der beiden einen anderen Port geben.

05 · Abschnitt

Häufige Stolperfallen

psql aus dem Terminal funktioniert nicht — PATH fehlt.

Postgres.app installiert die Binaries unter /Applications/Postgres.app/Contents/Versions/latest/bin/, Homebrew unter /opt/homebrew/opt/postgresql@18/bin/. Beide sind nicht automatisch im PATH. Wer das auslässt, bekommt command not found: psql und glaubt, die Installation sei kaputt.

Mehrere Postgres-Versionen parallel — nur mit unterschiedlichen Ports.

Postgres.app, Homebrew-Postgres und ein Docker-Container belegen alle per Default Port 5432. Wer mehrere gleichzeitig laufen lassen will, muss bei mindestens einem den Port ändern (Postgres.app im UI, Homebrew via postgresql.conf, Docker via -p 5433:5432).

Beim Major-Upgrade über Homebrew bleibt das alte Daten-Verzeichnis stehen.

brew upgrade postgresql sprang früher gerne von 15 auf 16 und ließ das Daten-Verzeichnis im alten Format zurück — der Server startete nicht mehr. Heute nutzen die meisten die versions-pinned Formel (postgresql@16, postgresql@17), womit Major-Upgrades ein bewusster Schritt sind: alte Formula installieren, pg_upgrade laufen lassen, neue Formula aktivieren.

Apple Silicon ≠ Intel-Pfade.

Auf M-Series-Macs liegt Homebrew unter /opt/homebrew, auf Intel unter /usr/local. Bei kopierten Anleitungen sind die Pfade für Daten-Verzeichnis und Konfiguration entsprechend zu übersetzen — sonst bearbeitest du die falsche postgresql.conf.

Default-Authentifizierung ist auf macOS sehr permissiv.

Postgres.app und Homebrew kommen mit trust für lokale Verbindungen — kein Passwort nötig. Bequem für Entwicklung, aber wer aus Versehen den Postgres-Port nach außen öffnet (z. B. via ngrok oder Port-Forwarding), hat eine offene Datenbank. Vor jedem solchen Schritt mindestens auf scram-sha-256 mit Passwort umstellen.

Docker Desktop frisst Performance bei großem I/O.

Wer mit großen Tabellen oder vielen Indexen arbeitet, merkt unter Docker Desktop auf macOS einen spürbaren I/O-Overhead — die VM-Grenze ist nicht kostenlos. Für CPU-lastige Queries fällt das kaum auf, für massenhaftes COPY schon. Alternativen: Volumes mit :cached mounten oder gleich auf Postgres.app zurückwechseln, falls die Produktion nicht containerisiert läuft.

06 · Abschnitt

Weiterführende Ressourcen

Externe Quellen

/ Weiter

Zurück zu Grundlagen

Zur Übersicht