Problem #1: Objects are not relations, relations are not objects

In an Object-Relational Mapper classes get mapped to tables; instances mapped to rows.

But in the relational model a table (base relation) is only one source of relations; relations can be composed from other relations, composed on the fly. An object is an object; I cannot change what it looks like at runtime, and its structure is practically static.

Problem #2: Object identity is not the same as the identity of a relation

The identify of a given row (tuple) in the relational model is in the candidate keys for that relation, whereas an object's identity is entirely in its pointer. This makes a number of operations problematic; for example identifying duplicates, indexing and searching for objects.

Problem #3: Poverty of operations

The relational algebra is made up of a whole bunch of interoperable operators. In the pure relational algebra I can take the result of a join, pipe it into a restriction, then a projection, then join that with something else, and so on. While SQL (which is only pseudo-relational) lacks much of this power, we lose it completely once we constrain our operations on data to those permissible by our object-relational mapping tool and its handicapped query languages.