Barrapunto

Pienso que los sistemas de archivos de journaling son claros ejemplos de base de datos especificamente diseñados para almacenar archivos. Si no me equivoco, el concepto d transaccion atomica se utiliza en los sistemas de journaling.
Por lo tanto considero redundante y una perdida de rendimiento, almacenar ficheros en campos de una base de datos.
Simplemente con almacenar la URI, una descripcion detallada del fichero y segun la necesidad, renombrarlo en forma univoca, es lo mas optimo.

El problema es luego hacer backups o replicaciones de los datos.

Un posible apaño es ser cuidadoso en el orden de las operaciones en la BD para luego poder hacer backups que tengan como mucho un exceso de datos (ficheros que no tienen representación en la BD), mejor que backups con perdidas. Aún así llevará tarde o temprano a errores y dificultará mucho los backups.

Se supone que la BD no tendrá problemas en escalar y soportar réplicas. No obstante con el sistema de archivos es más complicado. Quizás las réplicas se pueden arreglar poniendo un servidor NFS y todos los servidores accediendo por red al repositorio de archivos, y se puede ganar velocidad con una SAN potentilla, pero ten en cuenta que estas operaciones no se pueden hacer con la página web y sistema funcionando... la base de datos ha de estar parada para no perder sincronía con el sistema de archivos.