Datenbank auf einem VPS: PostgreSQL oder MySQL
Eine Datenbank stößt fast nie zuerst an die Grenzen des Prozessors, sondern an die von Arbeitsspeicher und Festplatte. Passt der aktiv genutzte Datenbestand in den Cache, laufen Abfragen selbst auf einem günstigen Server schnell; passt er nicht hinein, entscheidet die Geschwindigkeit der Festplatte. Hier lesen Sie, wie Sie zwischen PostgreSQL und MySQL wählen, wie viel Arbeitsspeicher die Datenbank bekommen sollte, welche Festplatte Sie brauchen und wie Sie keine Daten verlieren.
Bei den meisten Websites und Anwendungen ist die Wahl des Datenbanksystems schon getroffen: WordPress, Bitrix und die meisten PHP-Systeme sind auf MySQL ausgelegt, viele Projekte mit Django, Rails und Go nutzen standardmäßig PostgreSQL. Haben Sie freie Wahl, bewältigen beide Datenbanken eine typische Last problemlos. Der Unterschied liegt darin, was Sie bequemer betreuen können und was Ihr Technologie-Stack unterstützt.
PostgreSQL oder MySQL
- MySQL und MariaDB sind der Standard für CMS und Onlineshops in PHP. Jedes Control Panel und jedes Shared Hosting unterstützt sie, es gibt mehr fertige Anleitungen, und der Umzug einer Website vom Hosting auf einen VPS besteht meist aus einem Dump und einem Import.
- PostgreSQL ist die Wahl für Anwendungen mit komplexen Abfragen, Berichten und strenger Datenintegrität. Es bietet mehr Datentypen (JSONB, Arrays, Bereiche) und unterstützt Erweiterungen wie PostGIS für Geodaten und pgvector für die Vektorsuche.
Ist das Projekt neu und gibt die Software kein Datenbanksystem vor, nehmen Sie das, mit dem Ihr Team vertraut ist: Auf einem Server mit 4–8 GB Arbeitsspeicher ist der Geschwindigkeitsunterschied zwischen beiden kleiner als der zwischen einer gut und einer schlecht konfigurierten Datenbank. Das Datenbanksystem in einem laufenden Projekt zu wechseln ist teuer, deshalb trifft man diese Entscheidung nur einmal.
Wie viel Arbeitsspeicher die Datenbank bekommen sollte
Beide Systeme halten häufig genutzte Daten in einem eigenen Cache, und dessen Größe ist nach der Installation die wichtigste Einstellung. Standardmäßig ist er klein, bei beiden 128 MB. Ohne Anpassung nutzt die Datenbank auf einem Server mit 8 GB Arbeitsspeicher diesen also kaum.
- PostgreSQL: Laut Dokumentation ist auf einem Server, der nur für die Datenbank da ist und mindestens 1 GB Arbeitsspeicher hat, ein vernünftiger Startwert für
shared_buffers25 % des Arbeitsspeichers. Mehr als 40 % zu vergeben bringt kaum etwas, denn PostgreSQL stützt sich zusätzlich auf den Dateicache des Betriebssystems. - MySQL (InnoDB): Laut Dokumentation von MySQL 8.4 erhält der Buffer Pool
innodb_buffer_pool_sizeauf dedizierten Datenbankservern häufig bis zu 80 % des physischen Arbeitsspeichers.
Das entscheidende Wort ist in beiden Fällen „nur für die Datenbank“. Laufen auf demselben VPS auch Webserver, PHP-FPM, Redis und Warteschlangen, bleibt für die Datenbank weniger übrig: Auf einem Server mit 4 GB, auf dem auch die Website läuft, sind für den Buffer Pool von MySQL 1–1,5 GB sinnvoll, nicht 3 GB. Den Rest brauchen die Prozesse der Anwendung und eine Reserve, sonst lagert der Server in den Swap aus, und die Datenbank wird langsamer als mit einem kleinen Cache.
Als Maßstab für die Servergröße dient die Menge der „heißen“ Daten, also der Tabellen und Indizes, auf die ständig zugegriffen wird. Passen sie vollständig in den Cache, erreichen die meisten Lesezugriffe die Festplatte gar nicht. Laut Katalog von accsly.io mit Stand November 2026 kostet ein VPS mit 4 GB Arbeitsspeicher im Median etwa 20 € im Monat, mit 8 GB etwa 36 €, mit 16 GB etwa 66 € und mit 32 GB etwa 119 € (aus Rubel umgerechnet und gerundet). Mehr zur Wahl von Arbeitsspeicher und Kernen lesen Sie im Artikel Wie viel Arbeitsspeicher und wie viele Kerne braucht eine Website?, Tarife ab 16 GB finden Sie auf der Seite VPS mit 16 GB RAM.
Festplatte und IOPS
Passen die Daten nicht in den Arbeitsspeicher, und außerdem bei jedem Schreibvorgang, greift die Datenbank mit kleinen zufälligen Operationen auf die Festplatte zu. Entscheidend sind hier weder die Kapazität noch die sequenzielle Geschwindigkeit aus der Tarifbeschreibung, sondern die Zahl der Ein- und Ausgabeoperationen pro Sekunde (IOPS) und die Latenz. Genau bei diesen Operationen ist NVMe einer SATA-SSD überlegen. Eine klassische Festplatte eignet sich für eine produktive Datenbank überhaupt nicht: Sie schafft einige hundert Operationen pro Sekunde, eine SSD Zehntausende.
Laut Katalog von accsly.io mit Stand November 2026 ist NVMe bei 41 % der 29.603 VPS-Tarife angegeben, und bei größeren Tarifen ist der Anteil höher: 38 % bei Tarifen mit 2 GB Arbeitsspeicher und 45 % bei Tarifen mit 32 GB. Einen Vergleich der Festplatten finden Sie im Artikel NVMe oder SSD: Gibt es einen Unterschied für die Website?, passende Tarife in der Auswahl VPS mit NVMe.
Die Werte in der Beschreibung eines VPS-Tarifs sind eine Obergrenze: Die Festplatte teilen Sie sich mit den Nachbarn auf demselben physischen Server, und viele Hoster begrenzen die IOPS pro virtueller Maschine. Die tatsächliche Geschwindigkeit prüfen Sie nach dem Kauf, solange Sie den Server noch zurückgeben können, mit dem Werkzeug fio und einem Test für zufälliges Lesen und Schreiben mit Blöcken von 4–16 KB. Wie das in der Testphase geht, erklärt der Artikel Ping und Geschwindigkeit eines VPS vor der Bezahlung prüfen.
Backups und Replikate
Ein Festplatten-Snapshot beim Hoster ist eine bequeme, aber nicht die zuverlässigste Kopie einer Datenbank: Ein Snapshot, der während eines Schreibvorgangs entsteht, muss beim Einspielen eventuell wie nach einem Absturz wiederhergestellt werden, und er liegt meist beim selben Hoster. Für die Datenbank erstellen Sie deshalb eigene Kopien mit den Mitteln des Datenbanksystems:
- Logischer Dump mit
pg_dumpfür PostgreSQL odermysqldumpfür MySQL. Für InnoDB-Tabellen erstellen Sie den Dump mit der Option--single-transaction; dann ist er, wie die Dokumentation von mysqldump beschreibt, konsistent, ohne dass Tabellen gesperrt werden. Das eignet sich für Datenbanken bis zu einigen Dutzend Gigabyte; eine große Datenbank aus einem Dump wiederherzustellen kann Stunden dauern. - Wiederherstellung auf einen Zeitpunkt: eine vollständige Kopie der Datenbankdateien plus ein fortlaufendes Archiv des Änderungsprotokolls. In PostgreSQL ist das die WAL-Archivierung, in MySQL das Binärlog. So kehren Sie zum Stand eine Minute vor einem fehlerhaften
DELETEzurück und nicht zum Stand der letzten Nacht.
Die Kopien liegen außerhalb des Datenbankservers, etwa in einem Objektspeicher oder auf einem separaten VPS in einem anderen Rechenzentrum, und werden regelmäßig durch eine Wiederherstellung geprüft. Allgemeine Regeln für Backups beschreibt der Artikel VPS-Backups: Strategien und Werkzeuge, Speicherorte für Kopien der Artikel Dateispeicherung auf einem VPS: Festplatten und Objektspeicher.
Ein Replikat ist eine zweite Kopie der Datenbank auf einem anderen Server, die Änderungen fast sofort übernimmt: über Streaming-Replikation in PostgreSQL oder die Replikation in MySQL. Damit können Sie bei einem Ausfall des Hauptservers schnell umschalten und ihn entlasten, indem Sie Berichte auf dem Replikat laufen lassen. Ein Backup ersetzt es aber nicht: Eine versehentlich gelöschte Tabelle verschwindet Sekundenbruchteile später auch auf dem Replikat.
Verwaltete Datenbank oder eigene auf dem VPS
Cloud-Anbieter bieten verwaltete Datenbanken an: Sie erhalten eine Verbindungsadresse, und Installation, Updates, Backups und Replikate übernimmt der Anbieter. In Amazon RDS etwa werden automatische Backups bis zu 35 Tage aufbewahrt, mit der Möglichkeit, auf einen Zeitpunkt wiederherzustellen.
- Eine verwaltete Datenbank lohnt sich, wenn niemand im Team die Verantwortung für die Datenbank übernehmen kann, wenn Sie Ausfallsicherheit mit automatischem Umschalten brauchen oder wenn ein Ausfall mehr kostet als der Aufpreis. Die Nachteile: Derselbe Arbeitsspeicher und dieselbe Festplatte kosten spürbar mehr als auf einem VPS, manche Einstellungen und Erweiterungen sind nicht verfügbar, und der Wechsel zu einem anderen Anbieter ist aufwendiger.
- Eine eigene Datenbank auf dem VPS ist günstiger und gibt Ihnen volle Kontrolle über Version, Einstellungen und Erweiterungen. Dafür sind Updates, Backups, die Überwachung des Speicherplatzes und Wiederherstellungstests Ihre Aufgabe. Mehr zu den Unterschieden der beiden Ansätze lesen Sie im Artikel Cloud-Server oder VPS.
Ein häufiger Kompromiss für ein kleines Projekt: die Datenbank auf demselben VPS wie die Website, mit einem täglichen Dump und einem Archiv des Änderungsprotokolls in einem separaten Speicher. Wächst die Datenbank auf einige Gigabyte „heiße“ Daten oder beginnt sie die Anwendung zu stören, zieht sie auf einen eigenen Server mit NVMe um. Den Datenbankport schließen Sie dann zum Internet hin und erlauben den Zugriff nur von den Adressen der Anwendung. Tarife für einen solchen Server finden Sie auf den Seiten VPS für PostgreSQL, VPS für MySQL und VPS für Datenbanken. Freien Speicherplatz und Abfragelatenz sollten Sie gleich in das Servermonitoring aufnehmen: Eine volle Festplatte ist der häufigste Grund, warum eine Datenbank stehen bleibt.