PostgreSQL-Prüfsummen vs. Performance: Warum wir freiwillig etwa 3 % TPS opfern und ruhiger schlafen

Zuletzt aktualisiert: 1. Dezember 2025 | Lesezeit: 22 Minuten

Bei Hosted Power sind wir Performance-Enthusiasten:

• Wir optimieren Kernel zum Spaß.
• Wir diskutieren beim Mittagessen über shared_buffers.
• Wir benchmarken Dinge, die niemand von uns zu benchmarken verlangt hat.
• Und dann haben wir ein Feature aktiviert, das Postgres um etwa 3 % verlangsamt.

In diesem Artikel erklären wir, warum ein kleiner Performance-Kompromiss zu einer erheblichen Steigerung der Datenintegrität und der betrieblichen Sicherheit führt, insbesondere für E-Commerce-Plattformen und DevOps-Teams mit geschäftskritischen Workloads.

Inhaltsverzeichnis

1. Warum ein bewusster Kompromiss von drei Prozent sinnvoll ist
2. Benchmark-Umgebung
3. Benchmark-Ergebnisse
4. Auswirkungen interpretieren
5. Warum Hosted Power Checksums standardmäßig aktiviert
6. Was das innerhalb von TurboStack bedeutet
7. Fazit

Warum ein bewusster Kompromiss von drei Prozent sinnvoll ist

Im Kern geht es bei leistungsstarkem Hosting um Geschwindigkeit, Stabilität und vorhersehbare Skalierbarkeit. Doch auch in diesem Kontext ist die reine Geschwindigkeit nur ein Teil der Gleichung. Die Korrektheit der Daten ist ebenso entscheidend.

PostgreSQL-Datenchecksums erkennen stille Beschädigungen innerhalb von Tabellen- und Indexseiten. Diese Fehlerarten sind besonders gefährlich, weil:

• nichts abstürzt
• keine Warnungen angezeigt werden
• das System weiterhin falsche Daten ausliefert

Im E-Commerce kann das Folgendes bedeuten:

• Bestellsummen, die unmerklich falsch sind
• Bestandszahlen, die mit der Zeit abweichen
• Replikate, die beschädigte Seiten verbreiten
• Backups, die wochenlang falsche Daten speichern

Durch die Aktivierung von Checksums überprüft PostgreSQL die Integrität jeder Seite, wenn sie von der Festplatte gelesen wird. Wenn etwas nicht stimmt, alarmiert das System Sie sofort, anstatt stillschweigend ungültige Ergebnisse zurückzugeben.

Die Kosten

Während unserer internen Benchmarks führte die Aktivierung von Datenchecksums zu:

• etwa drei bis dreieinhalb Prozent weniger Durchsatz (TPS)
• etwa ein bis zwei Prozent höherer durchschnittlicher Latenz

Ein geringer Preis angesichts des betrieblichen Risikos, das dadurch entfällt.

Benchmark-Umgebung

Für eine faire Bewertung haben wir eine kontrollierte und wiederholbare Benchmark-Umgebung aufgebaut. Wir benchmarkten PostgreSQL 18 mit und ohne Datenchecksums auf einem Node mit 16 Kernen und 64 GB.

Hardware

Software

Datenbank

Wir verwendeten pgbench mit einem Skalierungsfaktor von 1500, wodurch etwa 24 GB an Tabellen und Indizes entstehen. Mit anderen Worten: eine realistische Dataset-Größe, ähnlich wie bei echten E-Commerce-Szenarien.

Workloads

Für dieses Experiment wollten wir die Art von Traffic nachbilden, die eine aktive E-Commerce-Plattform an einem normalen Tag erlebt. Das bedeutet zwei sehr unterschiedliche Verhaltensweisen: Kunden, die mit dem Shop interagieren und Änderungen vornehmen, sowie Besucher, die lediglich stöbern.

Read-Write-OLTP-Workload

Dieser Workload bildet echte Kundenaktivität ab. Er folgt dem standardmäßigen pgbench-Transaktionsmodell, das eine Mischung aus Vorgängen ausführt:

• mehrere UPDATE-Anweisungen zum Ändern von Daten
• ein SELECT zum Lesen von Informationen
• ein INSERT in die Verlaufstabelle

In der Praxis ähnelt dies einem Kunden, der Produkte durchsieht, Artikel in den Warenkorb legt, die Seite aktualisiert oder eine Bestellung abschließt. Dies ist ein guter Näherungswert für den stark ausgelasteten, sich ständig verändernden Traffic eines Onlineshops.

Read-only-Workload

Dieser Workload konzentriert sich vollständig auf das Lesen von Daten und verwendet den pgbench-Modus -S.

• Er führt große Mengen an SELECT-Abfragen aus
• Er bildet Kunden nach, die Katalogseiten durchsuchen, Produkte filtern oder eine große Produktsammlung durchsuchen

Damit lässt sich beobachten, wie sich PostgreSQL unter hoher Leselast verhält, ohne dass im Hintergrund Schreibvorgänge stattfinden.

Parallelitätsstufen

Um die Performance unter verschiedenen Belastungsstufen zu verstehen, haben wir zwei Szenarien getestet:

• Hohe Parallelität: 256 Clients, die gleichzeitig über 16 Threads für 300 Sekunden ausgeführt wurden. Dies bildet echte Spitzenlastbedingungen ab.
• Moderate Parallelität: 32 Clients über 8 Threads. Dies diente vor allem dazu zu veranschaulichen, wie kleine Tests Rauschen oder irreführende Ergebnisse verursachen können.

Checksum-Modi

Um die Auswirkungen von Datenchecksums isoliert zu betrachten, führten wir die Benchmarks in zwei Konfigurationen aus:

• ein Cluster mit aktivierten Checksums
• ein identischer Cluster mit deaktivierten Checksums

Alles andere blieb in der Umgebung exakt gleich. So stellten wir sicher, dass die Ergebnisse ausschließlich den Effekt der Checksums und nichts anderes verglichen.

Benchmark-Ergebnisse

Read-Write-OLTP bei hoher Parallelität

Auswirkung: etwa 3 % weniger Durchsatz und eine um 1.4 % höhere Latenz.

Read-only-Workload bei hoher Parallelität

Selbst bei reinem Select-Traffic bleibt die Auswirkung der Verwendung von Checksums bei etwa 3 %.

Test mit moderater Parallelität

Als wir die Last reduzierten und den Test mit nur 32 Clients ausführten, geschah etwas Merkwürdiges. Die Ergebnisse legten plötzlich nahe, dass die Aktivierung von Checksums PostgreSQL deutlich schneller machte.

So sahen die Zahlen aus:

Wenn man dies für bare Münze nimmt, scheint es zu bedeuten, dass die Aktivierung von Checksums das System um mehr als achtzig Prozent schneller macht. Das wäre erstaunlich, ist aber unmöglich.

Tatsächlich ist etwas ganz Einfaches passiert: Dieser Durchlauf wurde durch normales Systemrauschen beeinflusst. Bei niedriger Parallelität werden selbst kleine Unterschiede übertrieben dargestellt. Faktoren wie ein bereits aufgewärmter Cache, Hintergrundaktivitäten des Betriebssystems oder sogar zeitliche Zufälligkeiten können die Ergebnisse verzerren.

Dieser Durchlauf ist kein Beleg dafür, dass Checksums die Performance verbessern. Stattdessen erinnert er uns eindrücklich daran:

• Einzelne Durchläufe können irreführend sein.
• Tests mit niedriger Parallelität sind besonders anfällig für Rauschen.
• Gutes Benchmarking erfordert immer mehrere Durchläufe und gesunde Skepsis.

Wir nehmen dieses Beispiel nicht wegen seiner Zahlen auf, sondern wegen der daraus gewonnenen Erkenntnis: Überprüfen Sie Ihre Ergebnisse immer.

Auswirkungen interpretieren

Wenn wir die Testläufe mit hoher Parallelität betrachten, also jene mit 256 Clients auf einer 24-GB-Datenbank, werden die Auswirkungen der Checksums sehr deutlich und erweisen sich als sehr gering.

Bei den anspruchsvollen Workloads beobachteten wir:

Auf einer Maschine mit 16 CPU-Kernen und 64 GB RAM ist dies ehrlich gesagt eine sehr geringe Auswirkung. Zum Vergleich: Ähnliche Schwankungen können durch alltägliche Ereignisse entstehen, zum Beispiel:

• Die Datenbank wählt einen geringfügig anderen Query-Plan.
• Ein Cronjob wird zu einem ungünstigen Zeitpunkt gestartet.

• Jemand startet mitten am Tag einen umfangreichen internen Bericht.

   

Die tatsächlichen Kosten stiller Beschädigung

Ohne Checksums kann PostgreSQL eine beschädigte Seite lesen, ohne dies zu erkennen. Die Datenbank stellt die Daten so dar, als wäre alles in Ordnung. Dies kann zu Folgendem führen:

• undefiniertem Verhalten bei Abfragen
• falschen Entscheidungen in der Geschäftslogik
• beschädigten Replikaten
• beschädigten Backups

Bei aktivierten Checksums wird eine Beschädigung sofort erkannt. Dadurch können Sie:

• auf einen fehlerfreien Node failovern
• mit Sicherheit aus einem Backup wiederherstellen
• verhindern, dass Replikate ungültige Daten verbreiten
• Grundursachen untersuchen, bevor die Abweichung gravierend wird

Für E-Commerce-Shops, die Tausende von Bestellungen pro Stunde abwickeln, ist dieser Unterschied enorm.

Warum Hosted Power Checksums standardmäßig aktiviert

Wir sind auf leistungsstarkes Hosting für E-Commerce-Plattformen, Digitalagenturen, SaaS-Produkte und DevOps-Teams spezialisiert. Unsere Kunden sind auf vorhersehbare Performance, korrekte Daten und eine Plattform angewiesen, die auch während starker Spitzenzeiten stabil bleibt.

Auf Grundlage unserer Tests und betrieblichen Erfahrungen lautet unsere offizielle Position:

PostgreSQL-Datenchecksums sind standardmäßig in allen Produktionsdatenbanken aktiviert.

Wir akzeptieren eine geringe Abweichung im synthetischen Benchmark und erhalten dafür:

• frühe Erkennung von Problemen
• zuverlässige Replikate und Backups
• ein geringeres Risiko bei Failovers und Migrationen
• eine verbesserte langfristige Datenintegrität

Dies ist keine Verschlechterung der Performance, sondern eine Verbesserung der Zuverlässigkeit.

Was das innerhalb von TurboStack bedeutet

TurboStack, unser leistungsstarkes PaaS, bietet eine einheitliche Oberfläche zur Verwaltung von Anwendungen, Datenbanken, Caching, Containern und Deployments über mehrere Cloud-Anbieter hinweg. Es wurde für Geschwindigkeit, Automatisierung und Stabilität entwickelt.

Die Aktivierung von Checksums entspricht den Grundprinzipien von TurboStack's:

• Performance mit Sicherheit: maximale Geschwindigkeit ohne Kompromisse bei der Integrität
• Vorhersehbarkeit: weniger unerwartete Ausfälle und klarere Diagnosen
• Sicherheit für Teams: E-Commerce-Manager, Entwickler und DevOps Engineers erhalten eine vertrauenswürdigere Plattform.

Mehrwert für unsere Kundenprofile

• E-Commerce-Plattformen profitieren von korrekten Preisen, konsistenten Beständen und einer stabilen Bestellabwicklung, auch bei Spitzenereignissen wie Black Friday.
• Digitalagenturen erleben weniger Probleme in der Produktion, eine reibungslosere Projektabwicklung und einen Hosting-Partner, der betriebliche Zuverlässigkeit ernst nimmt.
• DevOps-Teams profitieren von einer vorhersehbaren Datenschicht, einer einfacheren Fehlerbehebung und vollständiger Kontrolle durch die Automatisierung und APIs von TurboStack.

Checksums stärken genau das, wofür TurboStack steht: eine leistungsstarke Plattform, die sowohl Geschwindigkeit als auch Genauigkeit priorisiert.

Fazit

Die Aktivierung von PostgreSQL-Datenchecksums ist ein bewusster und fundierter Kompromiss. Eine geringfügige Verringerung der synthetischen Performance um drei Prozent führt zu einer erheblichen Steigerung der betrieblichen Integrität und langfristigen Stabilität.

Für E-Commerce-Unternehmen, Agenturen und DevOps-Teams sind korrekte Daten wichtiger, als geringfügige TPS-Gewinne herauszuholen. Die Kosten unbemerkter Beschädigungen übersteigen den minimalen zusätzlichen Aufwand der Validierung bei weitem.

Hosted Power aktiviert Checksums daher mit voller Überzeugung standardmäßig und stellt so sicher, dass jede auf unserer Plattform ausgeführte Anwendung von höherer Zuverlässigkeit, sichereren Failovers und vorhersehbarem Verhalten unter hoher Last profitiert.

Wenn Sie erfahren möchten, wie wir die Performance und Stabilität Ihrer Infrastruktur steigern können, helfen wir Ihnen gerne weiter.

Suchen Sie nach Datenbank-Performance mit maximaler Geschwindigkeit und Genauigkeit?

Kontaktieren Sie uns