Comment tranchez-vous entre une base relationnelle et un magasin de documents pour un nouveau service ?

Commencez en relationnel sauf raison précise de faire autrement. Postgres vous donne les transactions, les jointures, les contraintes et un planificateur de requêtes, ce qui couvre la plupart des charges et garde vos options ouvertes. Prenez un magasin de documents quand le motif d'accès est vraiment une clé pour un blob, quand le schéma varie réellement d'un enregistrement à l'autre, ou quand vous avez besoin d'un débit d'écriture supérieur à ce qu'un seul primaire peut encaisser.

Mon défaut, c'est Postgres, et je veux qu'on m'en dissuade plutôt qu'on m'y pousse. La raison, c'est qu'une base relationnelle me donne les transactions, les jointures et les contraintes gratuitement, donc je n'ai pas à deviner correctement mes motifs d'accès dès le premier jour. Les modèles de données survivent aux services qui les écrivent, et je préfère garder la souplesse dans la couche de requête plutôt que dans la couche de stockage. Je prends bien un magasin de documents dans des cas précis. Si chaque enregistrement est réellement autonome, si la forme varie selon le locataire, ou s'il me faut un débit d'écriture au-delà d'un seul primaire, l'arbitrage a du sens. Ce sur quoi j'essaie d'être honnête, c'est le coût : sans jointures, chaque relation devient du code applicatif, et sans transactions, chaque mise à jour multi-documents devient un problème d'idempotence. Sur mon dernier projet, on a gardé les entités centrales dans Postgres et mis un journal d'événements à fort volume dans quelque chose fait pour ça, ce qui nous a donné l'échelle là où on en avait besoin sans renoncer à la justesse partout ailleurs.