PostgreSQL checksums vs. Performance - Waarom wij bewust ~3% TPS opofferen

Laatst bijgewerkt: december 2025 | Leestijd: 22 minuten

Bij Hosted Power zijn we verslaafd aan performance. We tunen kernels voor ons plezier, benchmarken dingen waar niemand om vroeg en discussieren tijdens de lunch over database instellingen. Toen PostgreSQL recent een feature introduceerde die de throughput met ongeveer 3% verlaagt, zou je dus verwachten dat we die meteen zouden afwijzen.

In plaats daarvan hebben we ze overal ingeschakeld. Heel bewust.

In dit artikel leggen we uit waarom een kleine performance trade off zorgt voor een grote winst in dataintegriteit en vertrouwen in de operatie, zeker voor e commerce platformen en DevOps teams die mission critical workloads draaien.

Inhoudstafel

1. Waarom een bewuste trade off van 3% logisch is
2. Benchmark omgeving
3. Benchmark resultaten
4. Hoe we de impact interpreteren
5. Waarom Hosted Power standaard checksums inschakelt
6. Wat dit betekent binnen TurboStack
7. Conclusie

Waarom een bewuste trade off van 3% logisch is

High performance hosting draait in essentie om snelheid, stabiliteit en voorspelbare schaalbaarheid. Maar zelfs in die context is pure snelheid maar een deel van het verhaal. De juistheid van data is minstens even belangrijk.

PostgreSQL data checksums detecteren stille corruptie in tabel en index pagina's. Dat zijn de gevaarlijkste fouten omdat:

• er niets crasht
• er geen waarschuwingen verschijnen
• het systeem gewoon verkeerde data blijft teruggeven

In e commerce kan dat betekenen:

• order totalen die subtiel fout zijn
• voorraadniveaus die langzaam wegdrijven
• replicas die corrupte paginas verder verspreiden
• backups die wekenlang verkeerde data bewaren

Door checksums in te schakelen controleert PostgreSQL de integriteit van elke pagina wanneer die van disk gelezen wordt. Als er iets fout is, krijg je meteen een melding in plaats van stilletjes fout resultaat.

Wat het kost

In onze interne benchmarks zorgde het inschakelen van data checksums voor:

• ongeveer drie tot drie komma vijf procent minder throughput (TPS)
• ongeveer een tot twee procent hogere gemiddelde latency

Een zeer kleine kost als je kijkt naar het operationele risico dat je ermee wegneemt.

Benchmark omgeving

Om een eerlijke evaluatie te maken hebben we een gecontroleerde en herhaalbare benchmark setup gebouwd. We hebben PostgreSQL 18 getest, met en zonder data checksums, op een node met 16 cores en 64 GB geheugen.

Hardware

Software

Database

We gebruikten pgbench met een schaalfactor van 1500, goed voor ongeveer 24 GB aan tabellen en indexen. Met andere woorden: een realistische dataset, vergelijkbaar met echte e commerce omgevingen.

Workloads

Voor dit experiment wilden we het soort verkeer nabootsen dat een actieve e commerce site op een normale dag ziet. Dat betekent grofweg twee soorten gedrag: klanten die echt iets wijzigen en bezoekers die vooral rondkijken.

Read write OLTP workload

Deze workload stelt echte klantactiviteit voor. Hij volgt het standaard pgbench transactiemodel en voert een mix van bewerkingen uit:

• meerdere UPDATE statements om data te wijzigen
• een SELECT om informatie op te halen
• een INSERT in de history tabel

In de praktijk lijkt dit op een bezoeker die producten bekijkt, items toevoegt aan het winkelmandje, de pagina ververst en een bestelling afrondt. Het is een goede benadering van het drukke, voortdurend veranderende verkeer van een webshop.

Read only workload

Deze workload focust volledig op leesverkeer en gebruikt de modus pgbench -S.

• Er worden zeer veel SELECT queries afgevuurd
• Het simuleert klanten die catalogus paginas bezoeken, producten filteren of door een grote productcatalogus zoeken

Dit is nuttig om te zien hoe PostgreSQL zich gedraagt onder zware leesbelasting zonder dat er schrijfsessies op de achtergrond lopen.

Concurrency niveaus

Om de performance bij verschillende stressniveaus te begrijpen, hebben we twee scenario's getest:

• Hoge concurrency: 256 clients die tegelijk draaien, verdeeld over 16 threads, gedurende 300 seconden. Dit benadert echte piekbelasting.
• Gemiddelde concurrency: 32 clients over 8 threads. Dit gebruikten we vooral om te tonen hoe kleinere tests ruis of misleidende resultaten kunnen geven.

Checksum modes

Om de impact van data checksums zuiver te meten, hebben we de benchmarks in twee configuraties uitgevoerd:

• een cluster met checksums ingeschakeld
• een identiek cluster met checksums uitgeschakeld

Voor de rest bleef de setup volledig identiek, zodat we enkel het effect van checksums zelf vergeleken.

Benchmark resultaten

Read write OLTP bij hoge concurrency

Impact: ongeveer 3 procent minder throughput en ongeveer 1.4 procent hogere latency.

Read only workload bij hoge concurrency

Zelfs bij puur leesverkeer blijft de impact van checksums rond 3 procent.

Test met gemiddelde concurrency

Toen we de belasting verminderden en de test draaiden met slechts 32 clients, gebeurde er iets vreemd. De resultaten leken plots te suggereren dat het inschakelen van checksums PostgreSQL veel sneller maakte.

Dit waren de cijfers:

Als je dit letterlijk neemt, lijkt het erop dat checksums inschakelen het systeem meer dan tachtig procent sneller maakt. Dat zou fantastisch zijn, maar het is niet realistisch.

Wat er echt gebeurde is eenvoudig: deze run werd beinvloed door normale systeempremies en ruis. Bij lage concurrency worden kleine verschillen extra uitvergroot. Zaken zoals een warme of koude cache, achtergrondprocessen van het besturingssysteem of gewoon timing effecten kunnen de resultaten sterk beinvloeden.

Deze run is dus geen bewijs dat checksums performance verbeteren. Het is eerder een perfecte reminder dat:

• een enkele testrun misleidend kan zijn
• tests met lage concurrency extra ruisgevoelig zijn
• degelijke benchmarking altijd meerdere runs en een gezonde dosis scepsis vereist

We tonen dit voorbeeld niet voor de mooie cijfers, maar voor de les erachter: controleer je resultaten altijd.

Hoe we de impact interpreteren

Als we kijken naar de testruns met hoge concurrency, met 256 clients op een database van 24 GB, wordt de impact van checksums tegelijk heel duidelijk en heel klein.

Voor de zware workloads zagen we:

Op een machine met 16 CPU cores en 64 GB RAM is dit eerlijk gezegd een zeer kleine impact. Ter vergelijking: je ziet vergelijkbare variaties door alledaagse gebeurtenissen zoals:

• de database die een iets ander query plan kiest
• een cron job die op een ongelukkig moment wakker wordt

• iemand die midden op de dag een groot intern rapport start

   

De echte kost van stille corruptie

Zonder checksums kan PostgreSQL een corrupte pagina lezen zonder dat te merken. De database blijft dan resultaten tonen alsof alles in orde is. Dat kan leiden tot:

• onvoorspelbaar gedrag in queries
• foute beslissingen in business logica
• replicas die beschadigd raken
• corrupte backups

Met checksums aan wordt corruptie meteen gedetecteerd, zodat je:

• kunt overschakelen naar een gezonde node
• met vertrouwen een backup kunt terugzetten
• kunt voorkomen dat replicas foute data verder verspreiden
• de root cause kunt onderzoeken voordat de afwijking ernstig wordt

Voor e commerce shops die duizenden orders per uur verwerken is dit verschil enorm.

Waarom Hosted Power standaard checksums inschakelt

We zijn gespecialiseerd in high performance hosting voor e commerce platformen, digital agencies, SaaS oplossingen en DevOps teams. Onze klanten rekenen op voorspelbare performance, correcte data en een platform dat stabiel blijft tijdens zware piekperiodes.

Op basis van onze testen en operationele ervaring is onze officiële positie:

PostgreSQL data checksums staan standaard aan op alle productie databases.

We aanvaarden een kleine penalty in synthetische benchmarks in ruil voor:

• vroege detectie van problemen
• betrouwbare replicas en backups
• minder risico bij failovers en migraties
• betere dataintegriteit op lange termijn

Dit is geen achteruitgang in performance, maar een upgrade in betrouwbaarheid.

Wat dit betekent binnen TurboStack

TurboStack, ons high performance PaaS platform, biedt een centrale interface om applicaties, databases, caching, containers en deployments over meerdere cloudproviders te beheren. Het is gebouwd voor snelheid, automatisering en stabiliteit.

Checksums inschakelen sluit perfect aan bij de kernprincipes van TurboStack:

• Performance met zekerheid: maximale snelheid zonder integriteit op te offeren
• Voorspelbaarheid: minder onverwachte fouten en duidelijkere diagnostiek
• Vertrouwen voor teams: e commerce managers, developers en DevOps engineers krijgen een platform waarop ze echt kunnen rekenen

Waarde voor onze klantprofielen

• E commerce platformen profiteren van correcte prijzen, consistente stock en stabiele orderverwerking, zelfs tijdens events zoals Black Friday.
• Digital agencies ervaren minder productieproblemen, vlottere opleveringen en een hostingpartner die operationele betrouwbaarheid serieus neemt.
• DevOps teams krijgen een voorspelbare datalaag, eenvoudigere troubleshooting en volledige controle via de automatisering en APIs van TurboStack.

Checksums versterken precies waar TurboStack voor staat: een high performance platform dat zowel snelheid als juistheid centraal zet.

Conclusie

PostgreSQL data checksums inschakelen is een bewuste, goed onderbouwde keuze. Een daling van drie procent in synthetische performance levert een grote winst op in operationele betrouwbaarheid en stabiliteit op lange termijn.

Voor e commerce bedrijven, agencies en DevOps teams is correcte data belangrijker dan elke laatste procent TPS. De kost van onopgemerkte corruptie weegt veel zwaarder dan de micro overhead van extra controles.

Hosted Power zet checksums daarom met volle overtuiging standaard aan, zodat elke applicatie op ons platform profiteert van hogere betrouwbaarheid, veiligere failovers en voorspelbaar gedrag onder druk.

Wil je weten hoe wij de performance en stabiliteit van jouw infrastructuur kunnen verbeteren, dan helpen we je graag.

Contacteer ons