Stored Procedures improve throughput by removing interactivity

It is best to keep transactions as short as possible for database efficiencies. If interactivity is allowed within a transaction, databases will need to support many concurrent transactions, most of them idle.

Most web applications take the user out of the equation by limiting a transaction to the duration of a web request. But it is still possible to have client/server style interactivity, one statement at a time. The application makes a query, reads the result, takes a decision, makes another query, etc. Queries and responses are sent back and forth between the application code and the database server, typically running on different machines.

In this interactive style of transaction, a lot of time is spent in network communications. This is especially undesirable in Serializable Isolation, where we want to avoid potential concurrency-related race conditions.

To avoid interactivity, one approach adopted in systems, especially with single-threaded serial transaction processing, is to get the application to submit the entire transaction code to the database ahead of time, as a Stored Procedure. Provided that all the data required by a transaction is in memory, the stored procedure can execute very fast, without network or disk I/O latencies.