J'ai utilisé une base de données de graphiques dans un emploi précédent. Nous n'utilisions pas neo4j, c'était un truc en interne construit sur Berkeley DB, mais c'était similaire. Il a été utilisé en production (il l'est toujours).
La raison pour laquelle nous avons utilisé une base de données de graphiques était que les données stockées par le système et les opérations que le système faisait avec les données étaient exactement le point faible des bases de données relationnelles et étaient exactement le point fort des bases de données de graphiques. Le système devait stocker des collections d'objets dépourvus de schéma fixe et liés entre eux par des relations. Pour raisonner sur les données, le système devait faire beaucoup d'opérations qui seraient quelques traversées dans une base de données de graphes, mais ce seraient des requêtes assez complexes en SQL.
Les principaux avantages du modèle graphique étaient le temps de développement rapide et la flexibilité. Nous pourrions rapidement ajouter de nouvelles fonctionnalités sans affecter les déploiements existants. Si un client potentiel souhaitait importer certaines de ses propres données et les greffer sur notre modèle, cela pouvait généralement être fait sur place par le commercial. La flexibilité a également aidé lors de la conception d'une nouvelle fonctionnalité, nous évitant d'essayer de regrouper de nouvelles données dans un modèle de données rigide.
Avoir une base de données étrange nous a permis de construire beaucoup de nos autres technologies étranges, nous donnant beaucoup de secret-sauce pour distinguer notre produit de ceux de nos concurrents.
Le principal inconvénient était que nous n'utilisions pas la technologie de base de données relationnelle standard, ce qui peut être un problème lorsque vos clients sont professionnels. Nos clients se demandaient pourquoi nous ne pouvions pas simplement héberger nos données sur leurs clusters Oracle géants (nos clients avaient généralement de grands centres de données). L'un des membres de l'équipe a en fait réécrit la couche de base de données pour utiliser Oracle (ou PostgreSQL ou MySQL), mais c'était légèrement plus lent que l'original. Au moins une grande entreprise avait même une politique Oracle uniquement, mais heureusement, Oracle a acheté Berkeley DB. Nous avons également dû écrire de nombreux outils supplémentaires - nous ne pouvions pas simplement utiliser Crystal Reports par exemple.
L'autre inconvénient de notre base de données de graphes était que nous l'avons construit nous-mêmes, ce qui signifiait que lorsque nous rencontrions un problème (généralement avec l'évolutivité), nous devions le résoudre nous-mêmes. Si nous avions utilisé une base de données relationnelle, le fournisseur aurait déjà résolu le problème il y a dix ans.
Si vous créez un produit pour les clients d'entreprise et que vos données s'intègrent dans le modèle relationnel, utilisez une base de données relationnelle si vous le pouvez. Si votre application ne correspond pas au modèle relationnel mais qu'elle correspond au modèle de graphique, utilisez une base de données de graphiques. Si cela ne correspond qu'à autre chose, utilisez-le.
Si votre application n'a pas besoin de s'intégrer dans l'architecture blub actuelle, utilisez une base de données de graphiques, ou CouchDB, ou BigTable, ou tout ce qui convient à votre application et que vous pensez que c'est cool. Cela pourrait vous donner un avantage et c'est amusant d'essayer de nouvelles choses.
Quoi que vous choisissiez, essayez de ne pas créer vous-même le moteur de base de données, sauf si vous aimez vraiment créer des moteurs de base de données.