Let's take an example from SQLAlchemy. I understand this is an ORM you feel is decent. http://docs.sqlalchemy.org/en/latest/orm/query.html http://docs.sqlalche

Let's take an example from SQLAlchemy. I understand this is an ORM you feel is decent. http://docs.sqlalchemy.org/en/latest/orm/query.html http://docs.sqlalchemy.org/en/latest/orm/query.html Note the section on joins. Their example is simple, a mapping between users and addresses. The ORM here generates a join in SQL. You are not avoiding it. The only alternative to generating SQL with a join is to write the join yourself. Such a thing would query users and then either lookup the address via an index or do a nested scan over addresses if you don't have an index. There is no way around it. Conceptually, a join is a description of a result set that you want. If you generate it, you are doing a join in some way. If you are doing full ACID with complex queries, then you still need to understand transactions and all the associated complexities. An ORM doesn't make any of that go away by using terminologies like sessions. Rather it limits you to some subset of SQL and schema design. If you want to limit your use of SQL for portability reasons, you can still do that without an ORM. At least that way you are more aware of what is actually going on under the hood and can more easily identify problems.