¿Cómo decides entre una base de datos relacional y un almacén de documentos para un servicio nuevo?

Empieza por relacional a menos que tengas una razón concreta para no hacerlo. Postgres te da transacciones, joins, restricciones y un planificador de consultas, lo que cubre la mayoría de las cargas y te mantiene las opciones abiertas. Tira de un almacén de documentos cuando el patrón de acceso sea de verdad una clave a un blob, cuando el esquema varíe realmente por registro, o cuando necesites un throughput de escritura por encima de lo que aguanta un solo primario.

Mi opción por defecto es Postgres, y quiero que me convenzan de salir de ahí, no de entrar. La razón es que una base de datos relacional me da transacciones, joins y restricciones gratis, así que no tengo que acertar con mis patrones de acceso el primer día. Los modelos de datos duran más que los servicios que escriben en ellos, y prefiero mantener la flexibilidad en la capa de consulta y no en la de almacenamiento. Sí tiro de un almacén de documentos en casos concretos. Si cada registro es realmente autocontenido, si la forma varía por tenant, o si necesito throughput de escritura por encima de un solo primario, el intercambio tiene sentido. Con lo que intento ser honesto es con el coste: sin joins, cada relación se convierte en código de aplicación, y sin transacciones, cada actualización de varios documentos se convierte en un problema de idempotencia. En mi último proyecto mantuvimos las entidades centrales en Postgres y pusimos un log de eventos de mucho volumen en algo construido para eso, lo que nos dio escala donde la necesitábamos sin renunciar a la corrección en todo lo demás.