Wie entscheidest du dich bei einem neuen Service zwischen einer relationalen Datenbank und einem Document Store?

Fang relational an, außer du hast einen konkreten Grund dagegen. Postgres gibt dir Transaktionen, Joins, Constraints und einen Query Planner, was die meisten Workloads abdeckt und dir Optionen offenhält. Greif zum Document Store, wenn das Zugriffsmuster wirklich ein Key auf einen Blob ist, wenn das Schema pro Datensatz tatsächlich variiert, oder wenn du mehr Write-Durchsatz brauchst, als ein einzelner Primary schafft.

Mein Default ist Postgres, und ich will davon abgebracht werden statt überzeugt. Der Grund ist, dass mir eine relationale Datenbank Transaktionen, Joins und Constraints gratis gibt, ich muss meine Zugriffsmuster also nicht an Tag eins richtig raten. Datenmodelle überleben die Services, die sie schreiben, und ich behalte die Flexibilität lieber im Query Layer als im Storage Layer. In bestimmten Fällen greife ich schon zum Document Store. Wenn jeder Datensatz wirklich in sich abgeschlossen ist, wenn die Form pro Tenant variiert, oder wenn ich mehr Write-Durchsatz brauche als ein einzelner Primary schafft, geht der Trade auf. Ehrlich sein will ich beim Preis: Ohne Joins wird jede Beziehung zu Anwendungscode, und ohne Transaktionen wird jedes Update über mehrere Dokumente zu einem Idempotenzproblem. Im letzten Projekt haben wir die Kernentitäten in Postgres gelassen und ein Event-Log mit hohem Volumen dort abgelegt, wo genau das hingehört, was uns Skalierung gab, wo wir sie brauchten, ohne überall sonst Korrektheit aufzugeben.