Postgres für einen Bot war eine Nummer zu groß

Als ich 2020 von JSON-Dateien auf eine Datenbank umgestiegen bin, habe ich genommen, was in jedem Tutorial stand. Später bin ich auf Postgres gewechselt, weil das als die ernsthafte Wahl galt.

Zwei Jahre später habe ich mir zum ersten Mal ernsthaft die Frage gestellt, ob das die richtige Wahl war. Die Antwort war differenzierter, als ich erwartet hatte.

Was ich tatsächlich brauchte

Ein ehrlicher Blick auf die Zahlen:

	Wert
Server	einige hundert
Datenbankzugriffe	im Schnitt wenige pro Sekunde
Datenmenge	im niedrigen dreistelligen Megabyte-Bereich
Schreibende Zugriffe	ein Bruchteil der lesenden
Gleichzeitige Verbindungen	drei Prozesse

Das ist Last, die ein Laptop nebenbei erledigt. Nichts davon verlangt eine Datenbank mit eigenem Serverprozess, Verbindungsverwaltung, Rollenkonzept und Netzwerkschicht.

Was Postgres mich gekostet hat

Ein zusätzlicher Dienst im Betrieb. Er muss laufen, aktualisiert, gesichert und überwacht werden. Bei einem Serverumzug ist er ein eigener Punkt auf der Liste. Bei einem Ausfall eine eigene Fehlerquelle.

Verbindungsverwaltung. Verbindungen sind endlich, und wenn drei Prozesse jeweils einen Pool halten, muss man rechnen. Ich habe genau dadurch zwei Ausfälle gehabt.

Ein Netzwerkweg mehr. Selbst lokal geht jede Abfrage durch eine Socket-Verbindung mit Protokoll. Das ist schnell, aber es ist eben nicht nichts — und bei vielen kleinen Abfragen summiert sich die Latenz.

Eine Sicherungsstrategie, die ich nie richtig hatte. Ein Dump ist schnell erstellt und wurde bei mir jahrelang nicht getestet. Bei einer Datei-basierten Datenbank ist die Sicherung eine Datei, die man kopieren und öffnen kann. Der Unterschied ist praktisch, nicht theoretisch: Was einfach ist, macht man.

Was Postgres mir gebracht hat

Der Vollständigkeit halber — es war nicht alles Nachteil:

Echte gleichzeitige Schreibzugriffe über mehrere Prozesse hinweg, ohne Sperrprobleme.
Datentypen, die Fehler früh verhindern: echtes Datum mit Zeitzone, JSON mit Prüfung, Aufzählungen.
Sprachliche Ausdrucksstärke bei Auswertungen — Fensterfunktionen, gemeinsame Tabellenausdrücke.
Erweiterungen, etwa für Volltextsuche.

Von dieser Liste habe ich zwei Punkte tatsächlich benutzt. Die Auswertungen, und die Datentypen. Beides gibt es bei anderen Datenbanken in ähnlicher Form.

Warum ich trotzdem erst später gewechselt habe

Ich habe diese Rechnung 2022 aufgemacht und trotzdem nichts geändert. Erst zwei Jahre später bin ich auf SQLite umgestiegen — und ich glaube, dass diese Verzögerung richtig war.

Der Grund: Ein Datenbankwechsel ist teuer und riskant, und der Nutzen war zu dem Zeitpunkt bloß Aufräumen. Es lief. Nichts war kaputt. Der Gewinn wäre weniger Betriebsaufwand gewesen — spürbar, aber kein akutes Problem.

Was den Ausschlag gegeben hat, war später ein anderer Umstand: Ich wollte die Datenbank zwischen Rechnern hin- und herschieben können, ohne Dumps und Wiederherstellungen. Genau dafür ist eine Datei-basierte Datenbank gebaut, und ab da war es keine Aufräumaktion mehr, sondern eine Verbesserung, die ich täglich merke.

Infobox

Für mich ist daraus eine Faustregel entstanden: Eine Architekturänderung, deren einziger Nutzen „das ist sauberer" ist, wartet. Eine, die einen konkreten Vorgang einfacher macht, den man regelmäßig hat, wird gemacht. Der Unterschied klingt nach Haarspalterei und trennt in der Praxis zwischen sinnvollen Umbauten und Beschäftigungstherapie.

Wie ich Datenbanken heute auswähle

Aus dieser Rückschau ist eine kurze Prüfliste geworden, die ich bei jedem neuen Projekt durchgehe. Sie fragt nicht nach Funktionen, sondern nach Betrieb.

Wie viele Prozesse schreiben gleichzeitig? Einer: Datei-Datenbank reicht. Mehrere auf derselben Maschine: geht, mit den richtigen Einstellungen. Mehrere auf verschiedenen Maschinen: Datenbankserver.

Wie sieht eine Sicherung aus, und wer spielt sie zurück? Wenn ich es bin und ich es selten mache, ist eine Datei unschlagbar.

Was passiert beim Umzug? Eine Datei kopiert man. Ein Server will installiert, konfiguriert und gefüllt werden.

Braucht jemand außer der Anwendung Zugriff? Wenn ja — Auswertungswerkzeuge, andere Dienste, Kollegen —, spricht das für einen Server mit eigener Nutzerverwaltung.

Wie groß werden die Daten? Bei Gigabyte ist alles möglich. Bei Terabyte wird die Frage anders.

Vier von fünf Antworten haben bei mir für die kleine Lösung gesprochen, und zwar seit Jahren. Ich habe die Umstellung trotzdem lange aufgeschoben — weil eine Änderung ohne konkreten Nutzen keine gute Änderung ist.

Der Punkt, der mir am wichtigsten geworden ist

Beim Nachdenken über diese Entscheidung ist mir aufgefallen, wie sie überhaupt zustande kam: Ich hatte sie nicht getroffen. Ich hatte übernommen, was in Tutorials stand, weil es nach der professionellen Variante aussah.

Solche Nicht-Entscheidungen sind in meinen Projekten die teuersten Posten gewesen. Nicht weil das Ergebnis falsch war — häufig war es sogar in Ordnung —, sondern weil ich die Gründe nicht kannte und deshalb später nicht beurteilen konnte, ob sie noch gelten.

Meine Gegenmaßnahme ist ein Satz pro Entscheidung, aufgeschrieben, wenn sie fällt: „Ich nehme X, weil Y, und würde Z wählen, wenn sich A ändert." Der dritte Teil ist der wertvollste — er enthält die Bedingung, unter der die Entscheidung neu zu prüfen ist. Ohne ihn bleibt jede Wahl für immer bestehen, weil niemand weiß, wann man sie hinterfragen sollte.

Was ich heute bei der Wahl beachte

Die Frage ist nicht „welche Datenbank ist besser", sondern welche zu der Form von Last und Betrieb passt.

Eine Datei-basierte Datenbank passt, wenn: ein einzelner Rechner ausreicht, die Zugriffe überwiegend lesend sind, die Datenmenge in Gigabyte statt Terabyte gemessen wird, und man Wert darauf legt, dass die Sicherung eine Datei ist.

Ein Datenbankserver passt, wenn: mehrere Rechner gleichzeitig schreiben, die Datenmenge groß ist, Nutzer- und Rechteverwaltung auf Datenbankebene gebraucht wird, oder man Funktionen benötigt, die es nur dort gibt.

Der Fehler, den ich 2020 gemacht habe, war nicht die Wahl von Postgres. Es war, die Wahl gar nicht als Entscheidung zu behandeln — sondern das zu nehmen, was in Tutorials stand, weil es nach der professionellen Variante aussah.

Genau diese Sorte Entscheidung — die man trifft, ohne zu merken, dass man eine trifft — sind rückblickend die teuersten. Nicht weil das Ergebnis falsch ist, sondern weil man die Gründe später nicht kennt und deshalb nicht überprüfen kann.