A lot of Rails performance problems do not start with obviously expensive code, but with code that looks harmless. For example: if order . line_items . present? # ... end That reads like a simple boolean check, ordinary Ruby. and not like a database operation. But on an unloaded Active Record association, that line may issue SQL. That is what makes it dangerous. Not the cost of one call, but the mismatch between how the code reads and what the system actually does. In Rails, some predicates are not purely local questions. They can cross the database boundary to answer what looks like an in-memory check. Once you see that, a lot of "mysterious" performance issues stop looking mysterious. Why this is easy to miss The method name is the trap. present? sounds like a lightweight predicate. In most Ruby code, that intuition is fine. You ask a question about a value that already exists in memory, and you get an answer. Associations break that expectation. When you call: order . line_items . present?…