OrientDB has some great explanations on their github wiki. Here is their thoughts on why references are better than joins: https://github.com/orientechnologies

OrientDB has some great explanations on their github wiki. Here is their thoughts on why references are better than joins: https://github.com/orientechnologies/orientdb/wiki/Tutorial:-Relationships#the-problem-with-joins https://github.com/orientechnologies/orientdb/wiki/Tutorial:... And this page gives an overview of relationships in general with OrientDB: https://github.com/orientechnologies/orientdb/wiki/Concepts#wiki-Referenced_relationships https://github.com/orientechnologies/orientdb/wiki/Concepts#... Personally I have found the relational model limiting for performance in certain use cases and limiting in terms of mental overhead in others. I have used MongoDB a lot, however only having embedding to model relationships is also very limiting. The promise of OrientDB is a documunt store with support for embedding (and class inheritance), but also being able to use references rather than joins. What embedding and references have in common is that you have to do more up front work to define your relationships. You can think of it as freezing the possible queries available in a relational model to the subset that you actually use. I think this is a great default for most applications. However, it is not what an analyst wants for doing ad-hoc queries, which SQL databases are great at. And even application creators often later decide that they want to do some ad-hoc analysis of data sitting in the database. This is where polyglot persistence should shine and you can have multiple databases that index the data in different ways.