I am not a DBA and I speak from experiences as a developer. Most ORM tools support Stored Procedures. Sometimes you might need to tweak something. For example, Entity Framework (at least in current reincarnation) will not work with Insert Stored Procedures that return newly inserted record ID as an output parameter. So, you might be forced to change your SP generator to return that ID as a recordset (Select SCOPE_IDENTYTY() AS ID) . This is some sacrifice of performance but it's not going to "make of break" your app or a database. As long as you do not deal with some heavy traffic applications the boost that you get in development, time-wise and code quality-wise, is worth having all those inserts and updates to use all fields in the table (assuming that ORM tool generates them that way). Performance issues are most often the result of badly written transaction code, misuse of business entities for reporting purposes and sometimes (rarely) using individual calls to Insert/Update/Delete when situation asked for sending a batch of statements.

I have seen code that would fetch an object after an object from a database 30,000 times to create one aspx form but I do not think that the blame should go to ORM. It was easy to see that page does not load right (even in development). It's just that people are rushed to write and check in code and nobody cares about consequences because the deadline has to be met (who cares about slow database under such circumstances) and only after things go to production and start causing trouble or make application unusable for end users we send escalation team to fix an issue.

Sorry for digression 🙂 but I would rather use ORM and deal with some issues that arise vs. write CRUD SPs or statements by hand. I would feel like moved back in time 10 years. We are supposed to deliver a business value and SQL server hardware and architecture could help with this a little :-).