PostgreSQL vs MariaDB voor transactionele CRUD-apps

Wanneer een CRUD-app een prototype ontgroeit

Een prototype CRUD-app voelt meestal snel omdat de data klein is, het team klein en het verkeer voorspelbaar. Je komt weg met eenvoudige queries, een paar indexen en handmatige schema-aanpassingen. Dan krijgt de app echte gebruikers, echte workflows en echte deadlines.

Groeien verandert de workload. Lijsten en dashboards worden de hele dag geopend. Meer mensen bewerken dezelfde records. Achtergrondjobs beginnen in batches te schrijven. Dat is wanneer "het werkte gisteren" verandert in trage pagina's, willekeurige time-outs en lock-waits tijdens piekuren.

Je bent waarschijnlijk over de grens als je dingen ziet zoals lijstpagina's die vertraagd raken na pagina 20, releases die data-backfills bevatten (niet alleen nieuwe kolommen), meer “flex-velden” voor metadata en integratiepayloads, of supporttickets die zeggen "opslaan duurt eeuwig" tijdens drukte.

Dan wordt het vergelijken van PostgreSQL en MariaDB minder een merkvoorkeur en meer een praktische vraag. Voor transactionele CRUD-workloads zijn de details die meestal de uitkomst bepalen: indexeringsopties naarmate queries complexer worden, migratieveiligheid zodra tabellen groot zijn, JSON-opslag en -querying, en queryfuncties die werk aan de applicatiezijde verminderen.

Dit artikel blijft gericht op die databasegedragingen. Het gaat niet diep in op servergrootte, cloudkosten of leverancierscontracten. Die zijn belangrijk, maar vaak later makkelijker te veranderen dan een schema- en querystijl waarop je product afhankelijk is.

Begin met je app-vereisten, niet met het databasemerk

Het betere startpunt is niet "PostgreSQL vs MariaDB." Het is het dagelijkse gedrag van je app: records aanmaken, een paar velden bijwerken, gefilterde resultaten tonen en correct blijven wanneer veel mensen tegelijk klikken.

Schrijf op wat je drukste schermen doen. Hoeveel reads zijn er per write? Wanneer treden pieken op (ochtendlogins, maandafsluitingen, grote imports)? Leg exact vast welke filters en sorteringen je gebruikt, want die sturen later het indexontwerp en de querypatronen.

Definieer daarna je niet-onderhandelbare eisen. Voor veel teams betekent dat strikte consistentie voor geld of voorraad, een audittrail voor "wie wat veranderde", en rapportagequeries die niet instorten elke keer dat het schema evolueert.

Operationele realiteit telt evenveel als features. Beslis of je een managed database draait of self-host, hoe snel je uit backups moet herstellen en wat je tolerantie is voor onderhoudsvensters.

Tot slot: definieer "snel genoeg" met een paar duidelijke doelen. Bijvoorbeeld: p95 API-latentie onder normale belasting (200–400 ms), p95 onder piekconcurrentie (misschien 2x normaal), maximale acceptabele lock-waits tijdens updates (onder 100 ms), en limieten voor backup- en hersteltijd.

Indexeringsprincipes die CRUD-snelheid bepalen

De meeste CRUD-apps voelen snel totdat tabellen miljoenen rijen bereiken en elk scherm een "gefilterde lijst met sortering" wordt. Op dat punt is indexering het verschil tussen een query van 50 ms en een timeout van 5 seconden.

B-tree-indexen zijn het standaardwerkpaard in zowel PostgreSQL als MariaDB. Ze helpen wanneer je op een kolom filtert, join-sleutels gebruikt en wanneer je ORDER BY overeenkomt met de indexvolgorde. Het echte prestativerschil komt meestal neer op selectiviteit (hoeveel rijen matchen) en of de index zowel filteren als sorteren kan afhandelen zonder extra rijen te scannen.

Naarmate apps volwassen worden, worden samengestelde indexen belangrijker dan enkel-kolom indexen. Een veelvoorkomend patroon is multi-tenant filteren plus een status plus sorteren op tijd, zoals (tenant_id, status, created_at). Zet het meest consistente filter eerst (vaak tenant_id), dan de volgende filter, en als laatste de kolom waarop je sorteert. Dit verslaat vaak losse indexen die de optimizer niet efficiënt kan combineren.

Verschillen komen naar voren met “slimmere” indexen. PostgreSQL ondersteunt partial en expression indexes, die geweldig kunnen zijn voor gerichte schermen (bijvoorbeeld alleen indexeren van "open" tickets). Ze zijn krachtig, maar kunnen teams verrassen als queries niet precies bij de predicate passen.

Indexen zijn niet gratis. Elke insert en update moet ook elke index bijwerken, dus je kunt gemakkelijk één scherm verbeteren en stilletjes alle writes vertragen.

Een eenvoudige manier om gedisciplineerd te blijven:

• Voeg een index alleen toe voor een echte query-pad (een scherm of API-call die je kunt benoemen).
• Geef de voorkeur aan één goede composietindex boven veel overlappende indexen.
• Controleer indexen na featurewijzigingen en verwijder dode ballast.
• Plan onderhoud: PostgreSQL heeft regelmatig vacuum/analyze nodig om bloat te vermijden; MariaDB vertrouwt ook op goede statistieken en af en toe opschoning.
• Meet vóór en ná, in plaats van op intuïtie te vertrouwen.

Indexeren voor echte schermen: lijsten, zoeken en paginatie

De meeste CRUD-apps besteden hun tijd aan een paar schermen: een lijst met filters, een zoekvak en een detailpagina. Je databasekeuze doet er minder toe dan of je indexen bij die schermen passen, maar de twee engines geven je verschillende tools zodra tabellen groeien.

Voor lijstpagina's denk in deze volgorde: eerst filter, dan sorteer, dan pagineer. Een veelvoorkomend patroon is "alle tickets voor account X, status in (open, pending), nieuwste eerst." Een composietindex die begint met de filterkolommen en eindigt met de sorteerkolom wint meestal.

Paginatie verdient speciale aandacht. Offset-paginatie (pagina 20 met OFFSET 380) wordt trager naarmate je scrolt omdat de database nog steeds door eerdere rijen moet lopen. Keyset-paginatie is constanter: je geeft de laatst geziene waarde door (zoals created_at en id) en vraagt om de “volgende 20 ouder dan die”. Het vermindert ook duplicaten en gaten wanneer nieuwe rijen verschijnen tijdens het scrollen.

PostgreSQL heeft een nuttige optie voor lijstschermen: "covering" indexes met INCLUDE, wat index-only scans mogelijk kan maken wanneer de visibility map dat toestaat. MariaDB kan ook covering reads doen, maar je bereikt dat meestal door de benodigde kolommen direct in de indexdefinitie op te nemen. Dat kan indexen breder en duurder maken om te onderhouden.

Je hebt waarschijnlijk betere indexen nodig als een lijst-endpoint vertraagt naarmate de tabel groeit, ook al retourneert het maar 20 tot 50 rijen, sorteren langzaam wordt tenzij je ORDER BY weglaat, of I/O toeneemt bij eenvoudige filters. Langere queries verhogen ook vaak lock-waits tijdens drukke periodes.

Voorbeeld: een orderscherm dat filtert op customer_id en status en sorteert op created_at profiteert meestal van een index die begint met (customer_id, status, created_at). Als je later "zoeken op ordernummer" toevoegt, is dat meestal een aparte index, niet iets dat je op de lijstindex plakt.

Migraties: releases veilig houden naarmate data groeit

Migraties stoppen snel met "een tabel veranderen" te zijn. Zodra er echte gebruikers en echte historie bestaan, moet je ook data-backfills, aanscherpen van constraints en het opruimen van oude datavormen kunnen uitvoeren zonder de app te breken.

Een veilige standaard is expand, backfill, contract. Voeg toe wat je nodig hebt op een manier die bestaande code niet verstoort, kopieer of bereken data in kleine stappen en verwijder het oude pad pas als je zeker bent.

In de praktijk betekent dat meestal het toevoegen van een nieuwe nullable kolom of tabel, backfillen in batches terwijl je writes consistent houdt, later valideren met constraints zoals NOT NULL, foreign keys en unieke regels, en pas dan oude kolommen, indexen en codepaden verwijderen.

Niet alle schema-wijzigingen zijn gelijk. Een kolom toevoegen is vaak laag risico. Een index toevoegen kan nog steeds duur zijn op grote tabellen, dus plan het voor lage belasting en meet het. Een kolomtype veranderen is vaak het meest riskant omdat het data kan herschrijven of writes kan blokkeren. Een veiliger patroon is: maak een nieuwe kolom met het nieuwe type, backfill, en schakel dan reads en writes over.

Rollbacks veranderen ook van betekenis op schaal. Schema-rollback is soms makkelijk; data-rollback vaak niet. Wees expliciet over wat je kunt terugdraaien, vooral als een migratie destructieve deletes of verliesgevende transformaties bevat.

JSON-ondersteuning: flexibele velden zonder toekomstige pijn

JSON-velden zijn verleidelijk omdat ze je sneller laten leveren: extra formuliervelden, integratiepayloads, gebruikersvoorkeuren en notities van externe systemen passen allemaal zonder schemawijziging. De truc is beslissen wat in JSON hoort en wat echte kolommen verdient.

In zowel PostgreSQL als MariaDB werkt JSON meestal het beste wanneer het zelden gefilterd wordt en vooral getoond wordt, bewaard voor debugging, gebruikt wordt als een "settings" blob per gebruiker of tenant, of voor kleine optionele attributen die geen rapportage aansturen.

Indexeren van JSON is waar teams verrast worden. Een JSON-sleutel één keer queryen is makkelijk. Filtreren en sorteren op die sleutel over grote tabellen is waar de performance kan instorten. PostgreSQL heeft sterke opties voor het indexeren van JSON-paden, maar je hebt nog steeds discipline nodig: kies een paar sleutels waarop je echt filtert en indexeer die, en houd de rest als niet-geïndexeerde payload. MariaDB kan ook JSON queryen, maar complexe "zoeken binnen JSON" patronen worden vaak fragieler en moeilijker snel te houden.

JSON verzwakt ook constraints. Het is moeilijker om "moet één van deze waarden zijn" of "altijd aanwezig" af te dwingen binnen een ongestructureerde blob, en rapportagetools geven meestal de voorkeur aan getypte kolommen.

Een regel die schaalt: begin met JSON voor onbekenden, maar normaliseer naar kolommen of child-tabellen wanneer je (1) erop filtert of sorteert, (2) constraints nodig hebt, of (3) het wekelijks in dashboards verschijnt. Het opslaan van de volledige shipping API-respons van een order als JSON is vaak prima. Velden zoals delivery_status en carrier verdienen meestal echte kolommen zodra support en rapportage ervan afhangen.

Queryfuncties die opduiken in volwassen apps

In het begin draaien de meeste CRUD-apps op eenvoudige SELECT, INSERT, UPDATE en DELETE. Later voeg je activity feeds, auditviews, admin-rapporten en zoekfunctionaliteit toe die direct moet aanvoelen. Dat is waar de keuze begint te lijken op een feature-tradeoff.

CTE's en subqueries helpen complexe queries leesbaar te houden. Ze zijn handig wanneer je een resultaat in stappen opbouwt (orders filteren, betalingen joinen, totals berekenen). Maar leesbaarheid kan kosten verbergen. Als een query traag wordt, moet je soms een CTE herschrijven als een subquery of join en dan het uitvoeringplan opnieuw controleren.

Window-functies worden belangrijk zodra iemand vraagt om "rank klanten op bestedingen", "lopende totalen" of "laatste status per ticket". Ze vervangen vaak ingewikkelde applicatielussen en verminderen het aantal queries.

Idempotente writes zijn een andere volwassen eis. Wanneer retries gebeuren (mobiele netwerken, achtergrondjobs), laten upserts je veilig schrijven zonder dubbele records te maken:

• PostgreSQL: INSERT ... ON CONFLICT
• MariaDB: INSERT ... ON DUPLICATE KEY UPDATE

Zoeken sluipt vaak binnen bij teams. Ingebouwde full-text search kan productcatalogi, kennisbanken en supportnotities dekken. Trigram-achtige zoekfuncties zijn nuttig voor type-ahead en fouttolerantie. Als zoeken core wordt (complexe ranking, veel filters, veel verkeer), kan een externe zoektool de extra complexiteit waard zijn.

Voorbeeld: een orderportaal begint met "lijst orders". Een jaar later moet het "toon elke klant's laatste order, rangschik op maandelijkse bestedingen, en zoek op verkeerd gespelde namen". Dat zijn databasemogelijkheden, niet alleen UI-werk.

Transacties, locks en concurrerende belasting

Wanneer het verkeer laag is, lijken de meeste databases prima. Onder belasting draait het vaak om hoe goed je gelijktijdige wijzigingen aan dezelfde data afhandelt, niet om ruwe snelheid. Zowel PostgreSQL als MariaDB kunnen een transactionele CRUD-workload draaien, maar je moet nog steeds ontwerpen voor contentie.

Isolatie in gewone taal

Een transactie is een groep stappen die samen moeten slagen. Isolatie bepaalt wat andere sessies kunnen zien terwijl die stappen draaien. Hogere isolatie voorkomt verrassende reads, maar kan wachttijden vergroten. Veel apps starten met defaults en verscherpen isolatie alleen voor flows die het echt nodig hebben (zoals het afschrijven van een kaart en het bijwerken van een order).

Wat echt lock-pijn veroorzaakt

Lockingproblemen in CRUD-apps komen meestal van een paar terugkerende oorzaken: hot rows die iedereen bijwerkt, tellers die bij elke actie veranderen, job-queues waar veel workers proberen hetzelfde "next job" te claimen, en lange transacties die locks vasthouden terwijl ander werk (of gebruikersinteractie) plaatsvindt.

Om contentie te verminderen: houd transacties kort, update alleen de kolommen die je nodig hebt en voorkom netwerkoproepen binnen een transactie.

Een nuttige gewoonte is herhalen bij conflicts. Als twee supportmedewerkers tegelijk wijzigingen opslaan op hetzelfde ticket, faal dan niet stilletjes. Detecteer het conflict, laad de laatste rij opnieuw en vraag de gebruiker om wijzigingen opnieuw toe te passen.

Om problemen vroeg te ontdekken, let op deadlocks, langlopende transacties en queries die tijd besteden aan wachten in plaats van uitvoeren. Maak slow query logs onderdeel van je routine, vooral na releases die nieuwe schermen of achtergrondjobs toevoegen.

Operaties die belangrijk worden na lancering

Na lancering optimaliseer je niet alleen voor query-snelheid. Je optimaliseert voor herstel, veilige verandering en voorspelbare prestaties.

Een veelvolgende stap is het toevoegen van een replica. De primary verwerkt writes en een replica kan read-zware pagina's zoals dashboards of rapporten bedienen. Dit verandert hoe je over freshness denkt: sommige reads kunnen enkele seconden achterlopen, dus je app moet weten welke schermen van de primary moeten lezen (bijvoorbeeld "bestelling zojuist geplaatst") en welke licht verouderde data kunnen verdragen (bijvoorbeeld wekelijkse samenvattingen).

Backups zijn maar de helft van het werk. Wat telt is of je snel en correct kunt herstellen. Plan regelmatige test-restores in een aparte omgeving en valideer basics: de app kan verbinden, sleutel tabellen bestaan en kritieke queries geven verwachte resultaten. Teams ontdekken vaak te laat dat ze het verkeerde hebben geback-upt of dat hersteltijd ver boven hun downtime-budget ligt.

Upgrades zijn ook geen "klik en hoop". Plan een onderhoudsvenster, lees compatibiliteitsnotities en test de upgrade-route met een kopie van productiegegevens. Zelfs kleine versie-updates kunnen queryplannen of gedrag rond indexen en JSON-functies veranderen.

Eenvoudige observability betaalt zich vroeg uit. Begin met slow query logs en topqueries op totale tijd, connection-saturatie, replicatie-lag (als je replicas gebruikt), cache-hitratio en I/O-druk, en lock-waits en deadlock-events.

Hoe te kiezen: een praktisch evaluatieproces

Als je vastloopt, stop dan met featurelijsten lezen en voer een kleine proef uit met je eigen workload. Het doel is geen perfecte benchmark, maar verrassingen vermijden wanneer tabellen miljoenen rijen bereiken en je releasecyclus versnelt.

1) Bouw een mini-test die op productie lijkt

Kies een onderdeel van je app dat representatief is voor echte pijn: een of twee sleutel-tabellen, een paar schermen en de write-paden erachter. Verzamel je topqueries (de queries achter lijstpagina's, detailpagina's en achtergrondjobs). Laad realistische rijaantallen (minstens 100x je prototype-data, met een vergelijkbare vorm). Voeg de indexen toe die je denkt nodig te hebben, voer dan dezelfde queries uit met dezelfde filters en sorteringen en leg timings vast. Herhaal terwijl writes plaatsvinden (een eenvoudig script dat rijen insert en update is genoeg).

Een snel voorbeeld is een "Customers"-lijst die filtert op status, zoekt op naam, sorteert op laatste activiteit en pagineert. Dat ene scherm onthult vaak of je indexering en planner-gedrag goed zal schalen.

2) Oefen migraties alsof het een echte release is

Maak een stagingkopie van de dataset en oefen veranderingen die je weet dat eraan komen: een kolom toevoegen, een type veranderen, data backfillen, een index toevoegen. Meet hoelang het duurt, of het writes blokkeert en wat rollback echt betekent wanneer data al veranderd is.

3) Gebruik een simpele scorecard

Beoordeel na het testen elke optie op performance voor je echte queries, correctheid en veiligheid (constraints, transacties, randgevallen), migratierisico (locking, downtime, herstelopties), ops-inspanning (backup/restore, replicatie, monitoring) en teamcomfort.

Kies de database die het risico voor de komende 12 maanden verkleint, niet degene die één micro-test wint.

Veelvoorkomende fouten en valkuilen

De duurste databaseproblemen beginnen vaak als "snelle wins." Beide databases kunnen een transactionele CRUD-app draaien, maar verkeerde gewoontes schaden beide zodra verkeer en data groeien.

Een veelvoorkomende val is JSON behandelen als een snelkoppeling voor alles. Een flexibel "extras"-veld is prima voor echt optionele data, maar kernvelden zoals status, timestamps en foreign keys moeten echte kolommen blijven. Anders eindig je met trage filters, ongemakkelijke validatie en pijnlijke refactors wanneer rapportage belangrijk wordt.

Indexering heeft zijn eigen valkuil: een index toevoegen voor elke filter die je op een scherm ziet. Indexen versnellen reads, maar vertragen writes en maken migraties zwaarder. Indexeer wat gebruikers daadwerkelijk gebruiken en valideer met gemeten load.

Migraties kunnen bijten als ze tabellen blokkeren. Big-bang veranderingen zoals het herschrijven van een grote kolom, het toevoegen van een NOT NULL met een default, of het creëren van een grote index kunnen writes minutenlang blokkeren. Breek risicovolle veranderingen in stappen en plan ze wanneer de app rustig is.

Vertrouw ook niet eeuwig op ORM-standaarden. Zodra een lijstweergave van 1.000 rijen naar 10 miljoen gaat, moet je queryplannen lezen, ontbrekende indexen spotten en trage joins repareren.

Snelle waarschuwingssignalen: JSON-velden gebruikt voor primaire filtering en sortering, een groeiend aantal indexen zonder meting van schrijfprestaties, migraties die grote tabellen in één deploy herschrijven, en paginatie zonder stabiele ordening (leidt tot missende en dubbele rijen).

Snelle checklist voordat je je vastlegt

Voordat je partij kiest, doe een korte realiteitscheck op basis van je drukste schermen en je releaseproces.

• Kunnen je top-schermen snel blijven tijdens piekbelasting? Test de traagste lijstpagina met echte filters, sortering en paginatie, en bevestig dat je indexen exact bij die queries passen.
• Kun je veilige schema-wijzigingen uitrollen? Schrijf een expand-backfill-contract-plan voor de volgende ingrijpende wijziging.
• Heb je een duidelijke regel voor JSON vs kolommen? Bepaal welke JSON-sleutels doorzoekbaar of sorteerbaar moeten zijn en welke echt flexibel zijn.
• Ben je afhankelijk van specifieke queryfuncties? Controleer upsert-gedrag, window-functies, CTE-gedrag en of je functionele of partial indexes nodig hebt.
• Kun je het na lancering beheren? Bewijs dat je kunt herstellen uit backup, meet slow queries en baseline latency en lock-waits.

Voorbeeld: van eenvoudige ordertracking naar een druk klantenportaal

Stel je een klantenportaal voor dat eenvoudig begint: klanten loggen in, bekijken orders, downloaden facturen en openen supporttickets. In week één voelt bijna elke transactionele database goed. Pagina's laden snel en het schema is klein.

Een paar maanden later komen groeimomenten naar voren. Klanten vragen filters zoals "orders verzonden in de laatste 30 dagen, betaald met kaart, met gedeeltelijke terugbetaling." Support wil snelle exports naar CSV voor wekelijkse reviews. Finance wil een audittrail: wie wijzigde een factuurstatus, wanneer en van wat naar wat. Querypatronen worden breder en gevarieerder dan de oorspronkelijke schermen.

Dat is waar de beslissing draait om specifieke features en hoe ze zich gedragen onder echte belasting.

Als je flexibele velden toevoegt (bezorginstructies, aangepaste attributen, ticketmetadata), wordt JSON-ondersteuning belangrijk omdat je uiteindelijk binnen die velden wilt zoeken. Wees eerlijk over of je team JSON-paden zal indexeren, shapes zal valideren en de performance voorspelbaar zal houden naarmate JSON groeit.

Rapportage is een ander drukpunt. Zodra je orders, facturen, betalingen en tickets joinet met veel filters, ga je geven om composietindexen, queryplanning en hoe makkelijk het is om indexen te evolueren zonder downtime. Migraties stoppen ook met "een script draaien op vrijdag" en worden deel van elke release, omdat een kleine schemawijziging miljoenen rijen kan raken.

Een praktische weg vooruit: schrijf vijf echte schermen en exports op die je over zes maanden verwacht, voeg audit-history-tabellen vroeg toe, benchmark met realistische datasizes met je traagste queries (niet een hello-world CRUD) en documenteer teamregels voor JSON-gebruik, indexering en migraties.

Als je snel wilt bewegen zonder elke laag handmatig te bouwen, kan AppMaster (appmaster.io) productieklare backends, webapps en native mobiele apps genereren vanuit een visueel model. Het spoort je ook aan om schermen, filters en bedrijfsprocessen vroeg als echte query-workloads te behandelen, wat helpt index- en migratierisico's te ontdekken voordat ze in productie problemen geven.