Postgres, zelf of beheerd
De standaardkeuze voor de meeste webapplicaties: relationeel, breed ondersteund en overal te draaien. Je kunt hem bij vrijwel elke aanbieder onderbrengen en later verhuizen zonder je model te herschrijven.
Een database kiezen voor je MVP
Bij een eerste versie wordt vaak lang gepraat over welke database het moet worden, terwijl dat zelden de beslissing is die je later opbreekt. Wat je wél vastlegt, is hoe je gegevens zijn gemodelleerd en bij welke partij ze staan. Hieronder waar het verschil zit en waar je op moet letten.
01/06
Waarom dit zelden de spannende keuze is
De meeste apps doen dingen die elke database prima aankan.
Een eerste versie slaat gebruikers op, wat records die bij die gebruikers horen en misschien een paar bestanden. Dat is voor elke serieuze database een makkelijke opgave. De prestatieverschillen waar online over geschreven wordt, worden pas merkbaar bij aantallen die je op dat moment nog niet hebt.
Wat wel telt is of je gegevens later te verplaatsen zijn en of je er normaal in kunt kijken. Een database waar je met gangbare hulpmiddelen bij kunt en waar je een dump van kunt maken, houdt je opties open. Een dienst die alleen via zijn eigen interface toegankelijk is, doet dat niet.
De keuze die je wel vastlegt, is hoe je je gegevens structureert. Een model dat niet klopt met hoe je organisatie werkelijk werkt, wreekt zich in elke functie die je daarna bouwt. Daar besteden we op een bouwdag meer aandacht aan dan aan het merk van de database.
02/06
De drie routes die je in de praktijk tegenkomt
Ze verschillen vooral in hoeveel je zelf beheert.
Een platform met Postgres eronder
Je krijgt database, authenticatie, bestandsopslag en een API in één. Dat scheelt opzetwerk en past goed bij een eerste versie. Omdat er een gangbare database onder zit, blijft vertrekken mogelijk.
Een documentdatabase
Gegevens als losse documenten in plaats van tabellen. Prettig als je model nog verandert en je snel wilt schakelen. Zodra je gaat rapporteren over verbanden tussen gegevens, wordt het meer werk dan een relationele database.
03/06
Waar je wél op moet letten
Vijf punten die zwaarder wegen dan de naam van het product.
- Kun je erbij zonder de dienst? Vraag jezelf af hoe je vandaag een volledige kopie van je gegevens zou maken. Is het antwoord onduidelijk, dan is dat het echte risico.
- Staan de gegevens waar ze mogen staan? Voor persoonsgegevens is de locatie van de opslag een vraag die je vooraf beantwoordt, niet nadat een klant ernaar vraagt.
- Zijn er back-ups en heb je een herstel geprobeerd? Een back-up die nooit is teruggezet, is een aanname. Probeer één keer een herstel, ook in een prototype: het duurt tien minuten en het verandert je vertrouwen.
- Groeit de prijs met wat je doet? Sommige diensten rekenen per verzoek of per gelezen record. Bij een dashboard dat elke minuut ververst, loopt dat anders op dan je verwacht.
- Past het model bij je werkelijkheid? Als klanten in jouw domein meerdere vestigingen hebben en je model gaat uit van één, bouw je die aanname in elke functie in. Dat is de vergissing die geld kost.
04/06
Relationeel of documenten
Een ruwe vuistregel die in de meeste gevallen klopt.
Relationeel ligt voor de hand
- Je gegevens hebben duidelijke verbanden: klanten, orders, regels, facturen.
- Je wilt rapporteren en optellen over die verbanden heen.
- Je wilt afdwingen dat een verwijzing altijd ergens naartoe wijst.
- Meerdere mensen bewerken dezelfde gegevens en volgorde doet ertoe.
Documenten kunnen prettiger zijn
- Elk record staat redelijk op zichzelf en heeft een wisselende vorm.
- Je model verandert nog wekelijks en je wilt niet steeds migreren.
- Je slaat vooral gebeurtenissen of losse documenten op.
- Realtime bijwerken van schermen is belangrijker dan complexe bevragingen.
05/06
Hoe we het op een bouwdag aanpakken
We besteden het eerste uur aan het model en daarna is de keuze meestal vanzelfsprekend.
Aan het begin van de dag tekenen we uit welke dingen er in jouw wereld bestaan en hoe ze zich tot elkaar verhouden. Dat gesprek levert vrijwel altijd een correctie op: iets wat je als één ding zag, blijkt er twee, of andersom. Dat is het waardevolste half uur van de dag.
Daarna kiezen we bijna altijd Postgres, meestal via een platform dat er authenticatie en opslag omheen levert. Dat is snel op te zetten, het model is er goed in uit te drukken en je zit nergens aan vast wat je later niet los kunt maken.
Wat we ook doen is meteen een export maken. Aan het eind van de dag heb je niet alleen een werkende app maar ook een bestand met je gegevensstructuur erin. Dat is je verzekering: wat er ook met de dienst gebeurt, je model ben je niet kwijt.
06/06
Veelgestelde vragen
Postgres of MySQL?
Voor een nieuwe applicatie is Postgres tegenwoordig de gebruikelijke keuze: rijker in mogelijkheden, goed met JSON-velden en breed ondersteund door hostingpartijen. MySQL is prima en je komt het vooral tegen in bestaande omgevingen. Het verschil is voor een eerste versie zelden doorslaggevend.
Is Firebase een slechte keuze?
Nee, het is een andere keuze. Het is snel op te zetten en sterk in realtime bijwerken van schermen. Het wordt lastiger zodra je wilt rapporteren over verbanden tussen gegevens, en het is minder eenvoudig te verlaten dan een gangbare relationele database. Weeg dat af tegen de snelheid die je er nu mee wint.
Wat als mijn AI-app-builder zelf een database meelevert?
Kijk dan welke database dat is. Zit er een gangbare relationele database onder waar je een kopie van kunt maken, dan is dat prima. Is het een eigen opslaglaag zonder export, dan zit je gegevensmodel vast aan die tool en dat is een groter probleem dan de rekening.
Moet ik nu al nadenken over schaalbaarheid?
Nauwelijks. De meeste applicaties komen met een enkele database heel ver, verder dan founders denken. Wat je nu wel doet, is een fatsoenlijk model en een paar verstandige indexen. Schalen is een probleem dat je liever hebt dan niet, en het is oplosbaar wanneer het speelt.
Hoe zit het met persoonsgegevens en de locatie van de opslag?
Kies een regio binnen de EU als je met persoonsgegevens werkt, en leg vast welke gegevens waar staan. De meeste aanbieders laten je die regio kiezen bij het aanmaken en niet daarna, dus dat is een beslissing die je aan het begin neemt.
Kan ik later van database wisselen?
Tussen relationele databases is dat goed te doen, zeker als je model netjes is. Van een documentdatabase naar relationeel is meer werk omdat je structuur moet afdwingen die er nog niet was. Dat is een reden om bij twijfel relationeel te beginnen.
