No, not without specific questions.

I could write a book about this and still not add something you haven't thought of.

ORM is excellent for models that don't fit well into matrices (tables).

Since you mentioned report performance, which are usually lists or tables, I'd guess your model is not of this kind, so ORM only logic is not recommended.

At first, you should balance ORM and database logic, leaving at least full integrity in database. If it later proves inflexible, you can move parts of it or all to ORM. The other way is a lot more difficult. If object code does not perform well, you can bypass it and access database directly. OO zealots will strongly oppose this, but if database takes care of its integrity, you can do it safely. If ORM takes care of integrity, you can't do it.

It's just like in OO languages when you have to access external non-OO API.

Code maintainability is simpler with ORM, as access to database is encapsulated in one layer, so, if you change/add/remove a column, application needs a change in one place. In classic app you can have several queries and code places affected by a change like this. In short, it's like discussion of OOP vs. PP, OOP is better, simpler, but requires a lot more planning and coding discipline. Planning phase gets significantly shorter with experience.