Voor een SaaS die moet schalen is de juiste standaardkeuze PostgreSQL. Het dekt zo’n 90% van wat een web- of mobiel product nodig heeft: transactionele data, relaties tussen entiteiten, zoeken, JSON, lichte queues en zelfs een deel van de vectorbelasting voor AI. De echte vraag is bijna nooit "relationeel of NoSQL", maar "heb ik een concrete reden om GEEN Postgres te nemen". Meestal niet.
PostgreSQL als standaard: waarom het 9 van de 10 keer werkt
Een SaaS verwerkt gestructureerde, onderling verbonden data: gebruikers die bij organisaties horen, abonnementen gekoppeld aan facturen, projecten gekoppeld aan taken. Precies waarvoor relationele databases gemaakt zijn. Postgres legt daar superkrachten bovenop, zodat je geen extra tools hoeft te stapelen: JSONB-kolommen voor het semigestructureerde, ingebouwde full-text search, de pgvector-extensie voor AI-embeddings en constraints die de integriteit van je data garanderen.
- ACID-transacties: je betalingen en kritieke data blijven consistent, zelfs na een crash.
- Eén systeem om te beheren, back-uppen en monitoren in plaats van drie: minder kosten, minder storingen.
- Volwassen ecosysteem: Prisma, migraties, replicatie, overal managed hosting (Cloud Run, Neon, Supabase, RDS).
- JSONB wanneer je flexibiliteit nodig hebt, zonder de rest relationeel op te geven.
Relationeel vs NoSQL: wanneer je Postgres verlaat
NoSQL (MongoDB, DynamoDB, Firestore) is niet "moderner", het beantwoordt andere eisen. Het loont alleen als je use case er echt bij past: enorm, schrijf-intensief volume, een werkelijk onvoorspelbaar schema of behoefte aan extreme geografische spreiding. Voor een typische B2B-SaaS in de lancerings- en groeifase bestaan die eisen nog niet, en NoSQL te vroeg invoeren laat je in complexiteit betalen voor iets wat je nooit zult gebruiken.
NoSQL kiezen omdat "het schaalt" terwijl je 200 gebruikers hebt, is een probleem optimaliseren dat je niet hebt, ten koste van de problemen die je al hebt.
Indexen, migraties, schalen: drie reflexen vanaf de V1
Een goed gekozen database is niet genoeg: drie gewoontes bepalen of je SaaS het houdt bij 10.000 gebruikers. Ten eerste indexen: een query die een hele tabel scant is snel bij 100 rijen en rampzalig bij 1 miljoen. Indexeer de kolommen waarop je vaak filtert en joint, en meet met EXPLAIN. Daarna migraties: elke schemawijziging moet geversioneerd en herspeelbaar zijn (Prisma Migrate), nooit met de hand in productie toegepast. Ten slotte schalen: eerst verticaal (meer CPU/RAM), dan read replicas, en aan sharding denk je pas heel laat: de meeste SaaS komen er nooit.
- Indexen: mik op de kolommen in WHERE-, JOIN- en ORDER BY-clausules; een verkeerde index kost bij het schrijven, een ontbrekende doodt het lezen.
- Migraties: geversioneerd, getest, omkeerbaar: de database evolueert mee met het product zonder downtime.
- Schalen: eerst verticaal, dan read replicas; Postgres verwerkt miljoenen rijen ruim voordat sharding ter sprake komt.
De juiste keuze voor een V1
PostgreSQL vanaf dag één kiezen, netjes modelleren, de juiste indexen leggen en migraties versioneren: dat bespaart je een herschrijving in maand 12. Het is precies de basis die we opzetten in onze V1"s, geleverd in 7 dagen voor € 15.000 — Next.js, NestJS, Prisma en Postgres —, een database die je meeneemt van je eerste klant tot de opschaling, zonder verborgen technische schuld.