DB stored procedure operation design - set based vs cursor based

Question

I'm told that when designing stored procedures, set based operations scale better than cursor based ones.

Can someone give a succinct explanation of why this is?

Answer 1

As succinctly as I can manage:

In relational database engines, all operations (whether in stored procedures or not) will usually* scale better using set-based logic simply because these engines are optimised for performing set-based operations.

There is a generally a fixed resource cost (which may be quite high) for a single atomic operation in the engine, whether it affects 1 or 1,000,000 rows.

Cursors incur even higher costs because the database engine must maintain the state of the cursor on top of the atomic operation cost.

*there are going to be a few edge cases/classes of problem (exactly which will depend on your RDBMS) in where procedural logic will perform better than set-based.

Answer 2

All (or almost all) RDMS are optimized for set-based operations, not row-based. For the most of the cases set-based solution overperforms row-based. For example, even SELECT * FROM table1 will perform many times faster than doing the same with cursors. However, there are some cases when cursor solution performs better. For example, calculating running aggregates using set-based approach in some RDMS(namely, SQLServer 2005) involves rescaning data several times, whereas cursor-based does it just once.
Another case when you need to use cursors is when the business logic of your application requires you to deal with each row individually.