I see - so in your case you gain from the fact that many of the joins are likely to result in zero matches. And since you're joining on a nullable FK, you can

I see - so in your case you gain from the fact that many of the joins are likely to result in zero matches. And since you're joining on a nullable FK, you can tell in advance whether the record exists without a lookup - I ran a test and I verified that you pay a cost for the below join regardless of whether the FK column is null. select * from Person p1 --p1.Spouse is null for the record in question join Person p2 on p1.Spouse = p2.PersonId where p1.PersonId = 42 (I understand why it can't do it in the execution plan, but I'm surprised it doesn't 'short-circuit' at runtime since the join predicate is trivially unsatisfiable for that row) Your other benefit involves conditionally needing data. I will say it's not too hard to structure app code to avoid loading redundant/unneeded data in your email example, but it's certainly easier and more maintainable when property access is fundamentally linked to its actual retrieval - it's impossible for another developer to make changes to your version and 'lose' the efficiency, while the same isn't true for mine. So it's less black and white than I thought...which it usually is :) How do you feel about using 'explicit' lazy loading? E.g. PersonEntity person; if(IWantToSendEmail){ person.Reference(x=>x.Email).Load(); //use email info here } This might be the best of both worlds...