Penso che il fatto che tu stia chiedendo un database di documenti è probabilmente una ragione sufficiente per usarlo. Generalmente l'aspetto più importante da considerare in scelte come questa è se la squadra ha abilità / esperienza con una tecnologia. Se sei aperto a provare un database di documenti, potrebbe essere sufficiente.
Ma, da un aspetto più tecnologico, i database di documenti generalmente significano cose come nessun join a livello di database, nessuna transazione, nessuna garanzia ACID. Dico "generalmente" perché ogni database di documenti è diverso. Quel genere di cose deve essere implementato a livello di applicazione. Se generalmente non si hanno aggiornamenti simultanei ai dati (o nessun aggiornamento, ad esempio una volta che un documento viene scritto, viene letto solo) i database dei documenti sono ottimali perché potrebbero non essere necessarie transazioni.
Se stai guardando dati strutturati ma non specifici, RDBMS, come dici tu, potrebbe essere molto impegnativo. Se ogni utente ha il potenziale per archiviare ciò che effettivamente diventa un dato strutturato su misura, un database di documenti sembra una scelta migliore. Ma dipende. Un archivio di chiavi / valori potrebbe funzionare anche molto bene in una situazione come questa.
Se stai guardando cose come ETL o rapporti, allora RDBMS 'a volte può essere una scelta migliore. Hanno una migliore selezione di strumenti per supportare cose come questa. Qualsiasi necessità di replica potrebbe anche influenzare la scelta di RDBMS o meno. Alcuni database di documenti supportano la replica e molti elementi di supporto.
se stai guardando la distribuzione dei dati, nosql in generale è spesso una scelta migliore. RDBMS può essere fatto funzionare in situazioni come questa ma può finire con alcuni problemi di prestazioni. Questo di solito non è un problema finché non si raggiungono carichi molto elevati su dati molto grandi.
Considerato lo stato attuale dei database di documenti, non riesco a pensare a molte situazioni in cui non si adattano realmente solo dal punto di vista dello storage dei dati. Esistono situazioni di grandi quantità di dati molto cariche in cui alcune implementazioni potrebbero introdurre alcuni problemi di prestazioni. Ma questo è davvero raro e spesso termina con la creazione di un nuovo database nosql progettato specificamente per lo scenario di quella organizzazione.
Suggerirei di implementare una dimostrazione del concetto rapida e sporca per avere un'idea del lavoro svolto. Se ritieni che la sua drasticità sia inferiore a quella di un RDBMS, questo potrebbe essere il fattore decisivo, a meno che non sia un requisito specifico di SQL come i rapporti di terze parti (come la BI).