PostgreSQL auf einem VPS: Architektur, Performance-Optimierung und Deployment-Leitfaden

PostgreSQL ist ein fortschrittliches, quelloffenes objektrelationales Datenbankmanagementsystem (ORDBMS), das sowohl SQL- als auch JSON-Abfragen, ACID-konforme Transaktionen und erweiterbare Datentypen unterstützt. Bei der Bereitstellung auf einem Virtual Private Server erhält es dedizierte Rechenressourcen, vollständigen Konfigurationszugriff auf Kernel-Ebene und Netzwerkisolierung – Funktionen, die Shared Hosting grundsätzlich nicht bieten kann.

Für Produktions-Workloads ist diese Kombination sofort relevant: Ein falsch konfigurierter shared_buffers-Wert auf Shared Hosting lässt sich nicht beheben, eine unkontrollierte Abfrage auf der Instanz eines Nachbarn kann Ihren I/O aushungern, und Sie können keine Erweiterungen wie PostGIS oder pg_partman ohne Root-Zugriff installieren. Ein VPS beseitigt alle drei Einschränkungen auf einmal.

Warum PostgreSQL andere Open-Source-RDBMS-Optionen übertrifft

Bevor wir die VPS-spezifischen Vorteile untersuchen, lohnt es sich zu verstehen, was PostgreSQL gegenüber MySQL/MariaDB zur bevorzugten Engine für komplexe Workloads macht.

PostgreSQLs Multi-Version Concurrency Control (MVCC)-Modell verdient besondere Erwähnung: Leser blockieren niemals Schreiber und Schreiber blockieren niemals Leser. Dies ist architektonisch überlegen für gemischte OLTP/OLAP-Workloads, bei denen lang laufende analytische Abfragen andernfalls Transaktionstabellen sperren würden.

Kosteneffizienz: Ressourcenzuweisung ohne Überbereitstellung

Ein VPS Hosting-Plan bietet garantierte CPU-Kerne, RAM und NVMe SSD-Speicher zu einem Bruchteil der Kosten von Bare-Metal-Hardware. Die wirtschaftliche Logik ist einfach: PostgreSQLs Speicheranforderungen skalieren mit max_connections und work_mem, nicht mit der reinen Servergröße. Ein ordnungsgemäß abgestimmter 4 GB RAM VPS, der 50 gleichzeitige Verbindungen bedient, wird eine 8 GB RAM-Instanz mit Standardeinstellungen und 200 inaktiven Verbindungen, die gemeinsamen Speicher verbrauchen, übertreffen.

Die praktische Kosteneffizienzstrategie besteht darin, mit einem mittleren VPS zu beginnen, Ihre tatsächlichen pg_stat_activity– und pg_stat_bgwriter-Metriken nach zwei Wochen Produktionslast zu analysieren und dann vertikal zu skalieren. Dieser datengesteuerte Ansatz verhindert den häufigen Fehler der Überbereitstellung beim Start.

Ein oft übersehener Kostenfaktor: PostgreSQLs autovacuum-Daemon benötigt CPU-Kapazitätsreserven. Auf Shared Hosting wird Autovacuum häufig vom Anbieter gedrosselt, was im Laufe der Zeit zu Tabellen-Bloat und verschlechterten Abfrageplänen führt. Auf einem VPS steuern Sie autovacuum_vacuum_cost_delay und autovacuum_max_workers direkt.

Vollständiger Root-Zugriff und Umgebungskontrolle

Im Gegensatz zu verwalteten Datenbankdiensten oder Shared Web Hosting gibt Ihnen ein VPS uneingeschränkten Zugriff auf die Betriebssystemebene. Dies ist nicht nur eine Bequemlichkeit – es ist eine zwingende Voraussetzung für mehrere PostgreSQL-Funktionen.

Was Root-Zugriff ermöglicht, das gemeinsame Umgebungen blockieren:

• Installation von PostgreSQL-Erweiterungen (CREATE EXTENSION postgis, CREATE EXTENSION pg_trgm, CREATE EXTENSION timescaledb)
• Änderung von Kernel-Parametern, die die PostgreSQL-Leistung direkt beeinflussen (vm.overcommit_memory, vm.swappiness, huge_pages)
• Konfiguration von pg_hba.conf mit benutzerdefinierten Authentifizierungsmethoden (SCRAM-SHA-256, LDAP, zertifikatsbasierte Authentifizierung)
• Ausführen von pg_upgrade für Hauptversionsmigration ohne Anbietereingriff
• Einbinden dedizierter Tablespace-Volumes auf separaten Blockgeräten zur I/O-Trennung zwischen Indizes und Heap-Dateien

Kritische Kernel-Optimierung für PostgreSQL unter Linux:

# Disable transparent huge pages (causes latency spikes in PostgreSQL)
echo never > /sys/kernel/mm/transparent_hugepage/enabled

# Set vm.overcommit_memory to allow PostgreSQL shared memory allocation
sysctl -w vm.overcommit_memory=2
sysctl -w vm.overcommit_ratio=80

# Reduce swappiness to prevent paging PostgreSQL shared buffers
sysctl -w vm.swappiness=1

# Persist these settings
echo "vm.overcommit_memory=2" >> /etc/sysctl.conf
echo "vm.overcommit_ratio=80" >> /etc/sysctl.conf
echo "vm.swappiness=1" >> /etc/sysctl.conf

Diese Einstellungen sind für verwaltete Datenbankdienste auf Anwendungsebene unsichtbar und sind häufig die eigentliche Ursache für unerklärliche Leistungsverschlechterungen in cloud-gehosteten PostgreSQL-Instanzen.

Leistungsoptimierung: Die postgresql.conf-Parameter, die wirklich wichtig sind

Die Standard-PostgreSQL-Installationsparameter sind absichtlich konservativ – sie sind darauf ausgelegt, auf einem 256 MB RAM-Rechner aus den frühen 2000er Jahren zu laufen. Auf einem modernen VPS mit 4–16 GB RAM und NVMe-Speicher lassen die Standardwerte den Großteil der Hardwarekapazität ungenutzt.

Speicherkonfiguration

# postgresql.conf — tuned for a 8 GB RAM VPS, OLTP workload

# Set to 25% of total RAM
shared_buffers = 2GB

# Estimate of OS cache available to PostgreSQL (typically 50-75% of RAM)
effective_cache_size = 6GB

# Per-sort/hash operation memory (multiply by max_connections for worst case)
work_mem = 32MB

# For VACUUM, CREATE INDEX, ALTER TABLE operations
maintenance_work_mem = 512MB

# Enable huge pages if kernel supports it
huge_pages = try

Die work_mem-Falle: Das Setzen von work_mem = 256MB mit max_connections = 100 bedeutet, dass PostgreSQL theoretisch 25,6 GB RAM allein für Sortiervorgänge zuweisen könnte – weit über den physischen Speicher hinaus und OOM-Kills auslösend. Berechnen Sie work_mem immer als: (available_RAM - shared_buffers) / (max_connections * 2).

Speicher- und WAL-Konfiguration

# For NVMe SSD storage — set to 1 for spinning disks, 200 for NVMe
random_page_cost = 1.1
effective_io_concurrency = 200

# WAL configuration for durability vs. performance tradeoff
wal_buffers = 64MB
checkpoint_completion_target = 0.9
checkpoint_timeout = 10min

# For write-heavy workloads, consider asynchronous commit
# (risk: last ~1 transaction lost on crash, not data corruption)
synchronous_commit = on  # Keep 'on' for financial data

Verbindungsverwaltung

# Avoid setting this above what your application actually needs
max_connections = 100

# Use PgBouncer in transaction pooling mode for high-concurrency apps
# A VPS allows you to install and configure PgBouncer locally

PgBouncer ist für Anwendungen mit mehr als 50 gleichzeitigen Benutzern nicht optional. Jeder PostgreSQL-Backend-Prozess verbraucht ungefähr 5–10 MB RAM. Bei 200 Verbindungen werden 1–2 GB durch inaktive Prozesse verbraucht. PgBouncer im Transaction-Pooling-Modus multiplext Hunderte von Anwendungsverbindungen auf einen kleinen Pool tatsächlicher PostgreSQL-Backends.

# Install PgBouncer on Debian/Ubuntu
apt install pgbouncer

# Minimal pgbouncer.ini configuration
cat /etc/pgbouncer/pgbouncer.ini

[databases]
mydb = host=127.0.0.1 port=5432 dbname=mydb

[pgbouncer]
listen_port = 6432
listen_addr = 127.0.0.1
auth_type = scram-sha-256
auth_file = /etc/pgbouncer/userlist.txt
pool_mode = transaction
max_client_conn = 1000
default_pool_size = 20

Sicherheitshärtung: Über die Standardinstallation hinaus

Eine frische PostgreSQL-Installation auf einem VPS weist mehrere Sicherheitslücken auf, die geschlossen werden müssen, bevor die Instanz vom Netzwerk aus erreichbar ist.

Netzwerkseitige Isolierung

PostgreSQL sollte niemals auf einer öffentlichen IP lauschen, es sei denn, dies ist absolut erforderlich. Binden Sie es an localhost und verwenden Sie SSH-Tunneling oder ein VPN für die Fernverwaltung.

# In postgresql.conf
listen_addresses = 'localhost'

# For replication or application servers on a private network only
# listen_addresses = '127.0.0.1,10.0.0.1'

Konfigurieren Sie pg_hba.conf, um SCRAM-SHA-256-Authentifizierung zu erzwingen (das Standard-md5 ist kryptografisch schwach):

# /etc/postgresql/16/main/pg_hba.conf
# TYPE  DATABASE        USER            ADDRESS                 METHOD
local   all             postgres                                peer
local   all             all                                     scram-sha-256
host    all             all             127.0.0.1/32            scram-sha-256
host    all             all             ::1/128                 scram-sha-256
# Reject all other connections by default (no catch-all line)

SSL/TLS-Verschlüsselung für Remote-Verbindungen

Wenn Ihr Anwendungsserver über ein Netzwerk eine Verbindung zu PostgreSQL herstellt, ist die Verschlüsselung der Verbindung obligatorisch. Kombinieren Sie dies mit einem SSL-Zertifikat für Ihre Anwendungsschicht und konfigurieren Sie PostgreSQLs eigenen TLS-Stack:

# Generate a self-signed certificate for internal use
openssl req -new -x509 -days 365 -nodes 
  -out /etc/postgresql/16/main/server.crt 
  -keyout /etc/postgresql/16/main/server.key

chmod 600 /etc/postgresql/16/main/server.key
chown postgres:postgres /etc/postgresql/16/main/server.{crt,key}

# postgresql.conf
ssl = on
ssl_cert_file = 'server.crt'
ssl_key_file = 'server.key'
ssl_min_protocol_version = 'TLSv1.2'

Rollenbasierte Zugriffskontrolle

Das Prinzip der minimalen Rechtevergabe gilt strikt für Datenbankrollen:

-- Create an application role with minimal permissions
CREATE ROLE app_user WITH LOGIN PASSWORD 'strong_password_here';
GRANT CONNECT ON DATABASE mydb TO app_user;
GRANT USAGE ON SCHEMA public TO app_user;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_user;

-- Create a read-only analytics role
CREATE ROLE analytics_reader WITH LOGIN PASSWORD 'another_strong_password';
GRANT CONNECT ON DATABASE mydb TO analytics_reader;
GRANT USAGE ON SCHEMA public TO analytics_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO analytics_reader;

-- Never use the superuser 'postgres' role for application connections

Firewall-Regeln

# Allow PostgreSQL only from specific application server IP
ufw allow from 10.0.0.5 to any port 5432
ufw deny 5432

# Verify
ufw status verbose

Backup- und Wiederherstellungsarchitektur

PostgreSQL bietet zwei grundlegend verschiedene Backup-Mechanismen, die jeweils für unterschiedliche Wiederherstellungsziele geeignet sind.

Logisches Backup mit Komprimierung:

# Dump a single database in custom format (supports parallel restore)
pg_dump -U postgres -Fc -Z 9 mydb > /backup/mydb_$(date +%Y%m%d).dump

# Restore
pg_restore -U postgres -d mydb_restored /backup/mydb_20240115.dump

# Dump all databases including roles and tablespaces
pg_dumpall -U postgres | gzip > /backup/full_cluster_$(date +%Y%m%d).sql.gz

Physisches Backup für Disaster Recovery:

# Take a base backup (can run while PostgreSQL is live)
pg_basebackup -U replication_user -D /backup/base -Ft -z -Xs -P

# This creates base.tar.gz and pg_wal.tar.gz
# Combined with WAL archiving, enables point-in-time recovery

Automatisierung mit cron:

# /etc/cron.d/postgres-backup
0 2 * * * postgres pg_dump -Fc mydb > /backup/mydb_$(date +%Y%m%d_%H%M).dump
0 3 * * 0 postgres pg_dumpall | gzip > /backup/full_$(date +%Y%m%d).sql.gz

# Prune backups older than 30 days
0 4 * * * root find /backup/ -name "*.dump" -mtime +30 -delete

Skalierbarkeit: Vertikal, horizontal und Leseskalierung

Vertikale Skalierung

Auf einem VPS ist die vertikale Skalierung (Hinzufügen von CPU, RAM, Speicher) typischerweise ein Live-Vorgang oder erfordert nur einen kurzen Neustart. Nach einem RAM-Upgrade aktualisieren Sie shared_buffers, effective_cache_size und work_mem proportional. Nach dem Hinzufügen von CPU-Kernen erhöhen Sie max_parallel_workers_per_gather und max_parallel_maintenance_workers.

# After upgrading from 4 to 8 CPU cores
max_parallel_workers_per_gather = 4
max_parallel_maintenance_workers = 2
max_parallel_workers = 8

Streaming-Replikation für Leseskalierung

PostgreSQLs integrierte Streaming-Replikation erstellt einen Hot-Standby, der Leseanfragen bedienen kann und damit Analyse-Workloads vom primären Server auslagert:

# On primary: create replication user
psql -U postgres -c "CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'rep_password';"

# In pg_hba.conf on primary
# host replication replicator 10.0.0.2/32 scram-sha-256

# In postgresql.conf on primary
# wal_level = replica
# max_wal_senders = 3
# wal_keep_size = 1GB

# On standby: initialize from primary
pg_basebackup -h 10.0.0.1 -U replicator -D /var/lib/postgresql/16/main 
  -P -Xs -R

# The -R flag creates standby.signal and populates primary_conninfo automatically

Logische Replikation für selektive Replikation

Die logische Replikation ermöglicht die Replikation bestimmter Tabellen auf eine andere PostgreSQL-Instanz, was für Data-Warehousing-Pipelines nützlich ist:

-- On publisher
CREATE PUBLICATION analytics_pub FOR TABLE orders, customers, products;

-- On subscriber
CREATE SUBSCRIPTION analytics_sub
  CONNECTION 'host=10.0.0.1 dbname=mydb user=replicator password=rep_password'
  PUBLICATION analytics_pub;

Für Anwendungen, die einen Dedicated Server für die primäre Datenbank mit VPS-Replikaten zur Verarbeitung des Leseverkehrs benötigen, bietet diese Architektur sowohl Leistung als auch Kosteneffizienz.

Erweiterte PostgreSQL-Funktionen, die es wert sind, aktiviert zu werden

JSONB für hybride relationale/dokumentenbasierte Workloads

-- Create a table with JSONB column
CREATE TABLE events (
  id BIGSERIAL PRIMARY KEY,
  occurred_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  payload JSONB NOT NULL
);

-- Create a GIN index for fast JSONB queries
CREATE INDEX idx_events_payload ON events USING GIN (payload);

-- Query nested JSON efficiently
SELECT * FROM events
WHERE payload @> '{"type": "purchase", "currency": "USD"}';

-- Extract and index a specific JSON key
CREATE INDEX idx_events_user_id ON events ((payload->>'user_id'));

Tabellenpartitionierung für große Datensätze

-- Range partitioning by month (ideal for time-series data)
CREATE TABLE measurements (
  id BIGSERIAL,
  recorded_at TIMESTAMPTZ NOT NULL,
  sensor_id INT,
  value NUMERIC
) PARTITION BY RANGE (recorded_at);

CREATE TABLE measurements_2024_01
  PARTITION OF measurements
  FOR VALUES FROM ('2024-01-01') TO ('2024-02-01');

CREATE TABLE measurements_2024_02
  PARTITION OF measurements
  FOR VALUES FROM ('2024-02-01') TO ('2024-03-01');

-- PostgreSQL automatically routes inserts and prunes partitions in queries

PostGIS für Geodaten-Anwendungen

# Install PostGIS extension
apt install postgresql-16-postgis-3

# Enable in database
psql -U postgres -d mydb -c "CREATE EXTENSION postgis;"

-- Store and query geographic coordinates
CREATE TABLE locations (
  id SERIAL PRIMARY KEY,
  name TEXT,
  geom GEOMETRY(Point, 4326)
);

-- Find all locations within 10km of a point
SELECT name, ST_Distance(geom::geography, ST_MakePoint(-73.935242, 40.730610)::geography) AS distance_m
FROM locations
WHERE ST_DWithin(geom::geography, ST_MakePoint(-73.935242, 40.730610)::geography, 10000)
ORDER BY distance_m;

Monitoring: Observability-Stack für produktives PostgreSQL

Reaktive Fehlerbehebung ist für Produktionsdatenbanken unzureichend. Ein proaktiver Observability-Stack erkennt Verschlechterungen, bevor sie zu einem Ausfall werden.

Integrierte PostgreSQL-Statistikansichten

-- Identify slow queries (requires pg_stat_statements extension)
CREATE EXTENSION pg_stat_statements;

SELECT query, calls, total_exec_time / calls AS avg_ms,
       rows / calls AS avg_rows
FROM pg_stat_statements
ORDER BY avg_ms DESC
LIMIT 20;

-- Check for table bloat and vacuum status
SELECT schemaname, relname, n_dead_tup, last_autovacuum, last_autoanalyze
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC;

-- Monitor replication lag
SELECT client_addr, state, sent_lsn, write_lsn, flush_lsn, replay_lsn,
       (sent_lsn - replay_lsn) AS replication_lag_bytes
FROM pg_stat_replication;

-- Find long-running queries
SELECT pid, now() - pg_stat_activity.query_start AS duration, query, state
FROM pg_stat_activity
WHERE (now() - pg_stat_activity.query_start) > interval '5 minutes';

Prometheus + postgres_exporter-Stack

# Install postgres_exporter
wget https://github.com/prometheus-community/postgres_exporter/releases/download/v0.15.0/postgres_exporter-0.15.0.linux-amd64.tar.gz
tar xzf postgres_exporter-0.15.0.linux-amd64.tar.gz
mv postgres_exporter-0.15.0.linux-amd64/postgres_exporter /usr/local/bin/

# Create a monitoring role in PostgreSQL
psql -U postgres -c "CREATE ROLE postgres_exporter WITH LOGIN PASSWORD 'monitor_pass';"
psql -U postgres -c "GRANT pg_monitor TO postgres_exporter;"

# Run the exporter
export DATA_SOURCE_NAME="postgresql://postgres_exporter:monitor_pass@localhost:5432/postgres?sslmode=disable"
postgres_exporter --web.listen-address=":9187"

Kombinieren Sie postgres_exporter mit einem Grafana-Dashboard (Dashboard-ID 9628 von grafana.com deckt alle kritischen PostgreSQL-Metriken ab) und konfigurieren Sie Alarme für: Replikationsverzögerung über 30 Sekunden, sich nähernden Transaction-ID-Wraparound, Cache-Hit-Rate unter 95% und Anzahl toter Tupel über 10% der lebenden Tupel.

Anwendungsfall-Matrix: PostgreSQL-Konfiguration an den Workload anpassen

Für Teams, die API-Backends oder Webanwendungen entwickeln, bietet die Kombination von PostgreSQL mit einem VPS mit cPanel ein verwaltetes Control Panel neben vollständiger Datenbankflexibilität. Für Infrastrukturteams, die CLI-gesteuerte Verwaltung bevorzugen, bietet VPS Control Panels eine breitere Auswahl an Panel-Optionen.

Praktische Entscheidungs-Checkliste vor der Bereitstellung von PostgreSQL auf einem VPS

Hardware-Dimensionierung:

• Berechnen Sie shared_buffers als 25% des gesamten RAM
• Überprüfen Sie NVMe SSD-Speicher – PostgreSQLs WAL-Schreibvorgänge sind latenzempfindlich
• Weisen Sie mindestens 2 dedizierte CPU-Kerne für Produktions-Workloads zu

Sicherheits-Baseline:

• Binden Sie listen_addresses nur an privat/localhost
• Ersetzen Sie md5 durch scram-sha-256 in pg_hba.conf
• Aktivieren Sie SSL mit mindestens TLS 1.2 für alle Remote-Verbindungen
• Erstellen Sie anwendungsspezifische Rollen – verwenden Sie niemals den postgres-Superuser im Anwendungscode
• Konfigurieren Sie ufw oder iptables, um nur bekannte Quell-IPs auf Port 5432 zuzulassen

Leistungs-Baseline:

• Deaktivieren Sie Transparent Huge Pages auf Betriebssystemebene
• Setzen Sie vm.swappiness=1, um das Auslagern von Shared Buffers zu verhindern
• Installieren und konfigurieren Sie PgBouncer, wenn die Verbindungsanzahl 50 überschreitet
• Aktivieren Sie pg_stat_statements von Anfang an – nachträgliche Abfrageprofilerstellung ist unmöglich

Backup und Wiederherstellung:

• Automatisieren Sie pg_dump mit cron, testen Sie Wiederherstellungen monatlich
• Implementieren Sie WAL-Archivierung, wenn RPO-Anforderungen unter 1 Stunde liegen
• Kombinieren Sie anwendungsseitige Backups mit VPS-Anbieter-Snapshots für mehrschichtigen Schutz

Observability:

• Stellen Sie postgres_exporter + Prometheus + Grafana vor dem Go-Live bereit
• Richten Sie Alarme für Replikationsverzögerung, Transaction-ID-Alter und Cache-Hit-Rate ein
• Überprüfen Sie pg_stat_bgwriter wöchentlich, um Checkpoint-Druck zu erkennen

FAQ

Welche PostgreSQL-Version sollte ich auf einem neuen VPS installieren?

Installieren Sie immer die neueste stabile Hauptversion (PostgreSQL 16 ab 2024) aus dem offiziellen PGDG-Repository, nicht die mit Ihrer Linux-Distribution gebündelte Version. Distributionspakete sind oft 1–2 Hauptversionen im Rückstand und erhalten keine Upstream-Feature-Backports. Verwenden Sie apt.postgresql.org oder yum.postgresql.org für die Installation.

Wie viel RAM benötigt ein PostgreSQL-VPS tatsächlich?

Für eine kleine Produktionsanwendung mit unter 50 gleichzeitigen Verbindungen und einem Datensatz unter 50 GB sind 4 GB RAM ein praktisches Minimum. Setzen Sie shared_buffers = 1GB, work_mem = 16MB und verwenden Sie PgBouncer. Für Datensätze, die den verfügbaren RAM überschreiten, konzentrieren Sie sich auf Index-Abdeckung und Abfrageplan-Optimierung, bevor Sie Hardware hinzufügen – ein fehlender Index auf einer 100 GB-Tabelle wird nicht durch das Hinzufügen von RAM gelöst.

Ist es sicher, PostgreSQL und die Anwendung auf demselben VPS zu betreiben?

Ja, für kleine bis mittlere Workloads. Das Risiko besteht in Ressourcenkonflikten: Ein Speicher-Spike in der Anwendung kann OOM-Kills auslösen, die PostgreSQL beenden. Mindern Sie dies, indem Sie PostgreSQLs oom_score_adj auf einen negativen Wert setzen (wodurch es weniger wahrscheinlich getötet wird) und cgroups verwenden, um die Speichergrenze der Anwendung zu begrenzen.

Was ist der Unterschied zwischen pg_dump und pg_basebackup?

pg_dump erstellt ein logisches Backup einer einzelnen Datenbank – es exportiert SQL-Anweisungen oder ein benutzerdefiniertes Binärformat, das selektiv wiederhergestellt werden kann (einzelne Tabellen, Schemata). pg_basebackup kopiert das gesamte PostgreSQL-Datenverzeichnis auf binärer Ebene und erstellt ein vollständiges Cluster-Backup, das für Disaster Recovery und die Initialisierung von Standby-Servern geeignet ist. Verwenden Sie beide: pg_dump für granulare Wiederherstellungen, pg_basebackup für vollständige Wiederherstellungsszenarien.

Wie führe ich ein sicheres Upgrade von PostgreSQL auf eine neue Hauptversion auf einem VPS durch?

Verwenden Sie pg_upgrade mit dem --check-Flag zuerst, um die Kompatibilität zu validieren, ohne Änderungen vorzunehmen. Erstellen Sie ein vollständiges pg_basebackup-Backup, bevor Sie fortfahren. Das Upgrade selbst wird offline durchgeführt (PostgreSQL muss gestoppt werden). Für Hauptversions-Upgrades ohne Ausfallzeit verwenden Sie logische Replikation: Richten Sie eine neue PostgreSQL 16-Instanz als logischen Subscriber des PostgreSQL 15-Primärservers ein, lassen Sie ihn aufholen und führen Sie dann einen koordinierten Cutover mit minimaler Ausfallzeit durch.