De database-keuze is een van de eerste architectuurbeslissingen die je maakt bij een nieuw project — en een van de moeilijkste om later te veranderen. Na jarenlang met verschillende databases te hebben gewerkt, deel ik mijn beslisframework.
Waarom ik bijna altijd PostgreSQL kies
Voor 90% van de webapplicaties die ik bouw, kies ik PostgreSQL. Niet omdat het de "beste" database is, maar omdat het de meest veelzijdige is.
Postgres kan (bijna) alles
-- Relationele queries
SELECT * FROM orders JOIN users ON orders.user_id = users.id;
-- JSON documenten
SELECT data->>'name' FROM profiles WHERE data @> '{"role": "admin"}';
-- Full-text search
SELECT * FROM posts WHERE to_tsvector('dutch', title) @@ to_tsquery('dutch', 'react & performance');
-- Geo queries
SELECT * FROM stores WHERE ST_DWithin(location, ST_MakePoint(4.89, 52.37), 5000);Eén database die SQL, JSON, full-text search en geo-queries ondersteunt. Dat betekent minder operationele complexiteit en minder bewegende delen.
Wanneer MongoDB de betere keuze is
MongoDB heeft een slechte reputatie gekregen door overmatig gebruik in situaties waar het niet past. Maar er zijn legitieme use cases:
Ongestructureerde of variabele data
Als elk document een andere structuur kan hebben — denk aan IoT sensor data, CMS content met variabele velden, of event logs — is MongoDB's flexibele schema een voordeel.
Extreme write-throughput
MongoDB's architecture is geoptimaliseerd voor hoge schrijfvolumes. Als je miljoenen documenten per seconde schrijft, kan MongoDB beter presteren dan Postgres.
Snel prototypen
Geen migraties, geen schema-definities. Start een collection en schrijf data. Voor een snelle proof-of-concept kan dit waardevol zijn.
Pas op
De flexibiliteit van MongoDB is ook het grootste risico. Zonder schema-validatie eindigt je met inconsistente data die je later pijn doet. Als je MongoDB kiest, gebruik dan Mongoose of Zod voor schema-validatie in je applicatie.
Database Keuze Wizard
Wat voor data heb je?
De opkomst van edge databases
Een interessante ontwikkeling: databases die aan de edge draaien, dicht bij je gebruikers.
| Database | Type | Latency | Use case |
|---|---|---|---|
| Turso (libSQL) | SQL | ~5ms | Edge-first apps |
| PlanetScale | MySQL-compatibel | ~10ms | Serverless MySQL |
| Supabase | PostgreSQL | ~20ms | Full-stack platform |
| Neon | PostgreSQL | ~15ms | Serverless Postgres |
| D1 (Cloudflare) | SQLite | ~1ms | Edge workers |
Gecentraliseerde database
- ❌Eén database in US-East regio
- ❌100ms+ latency voor EU gebruikers
- ❌Alle queries naar dezelfde server
- ❌Single point of failure
- ❌Verticaal schalen (grotere server)
Edge database
- ✅Database replicas in elke regio
- ✅5ms latency voor lokale gebruikers
- ✅Reads lokaal, writes naar primary
- ✅Automatische failover
- ✅Horizontaal schalen (meer replicas)
Mijn stack per project type
Na jaren experimenteren heb ik een duidelijk patroon:
| Project type | Database | ORM | Waarom |
|---|---|---|---|
| SaaS applicatie | Supabase (Postgres) | Drizzle | Auth + realtime + storage ingebouwd |
| Marketing site + blog | SQLite / Velite | - | Geen server nodig |
| High-traffic API | Neon (Postgres) | Drizzle | Serverless scaling |
| Realtime app | Supabase | Drizzle | Realtime subscriptions |
| Analytics dashboard | TimescaleDB | SQL | Time-series geoptimaliseerd |
Mijn advies
Begin met PostgreSQL (via Supabase of Neon). Voeg Redis toe als je caching of session storage nodig hebt. En voeg een gespecialiseerde database pas toe als je kunt aantonen dat Postgres niet voldoet voor een specifieke use case.
Conclusie
De "beste" database bestaat niet. Maar voor de meeste webapplicaties is PostgreSQL met een moderne ORM (Drizzle of Prisma) de veiligste keuze. Het is veelzijdig, bewezen, en schaalbaar genoeg voor alles behalve de meest extreme workloads.
Kies saai. Kies bewezen. Kies PostgreSQL.