使用程序有許多優點，主要在於使用程序會將 SQL 陳述從應用程式移動到資料來源。 應用程式中剩下的是一個可互通的程序呼叫。 這些優點包括：
性能 程序通常是執行 SQL 陳述式最快速的方式。 與預備執行類似，該語句會被分為兩個獨立步驟進行編譯和執行。 與準備執行不同，程序僅在執行時執行。 它們是在不同的時間編纂的。
商業規則商業規則是關於公司經營方式的規則。 例如，只有具有「銷售人員」職稱的人才被允許新增銷售訂單。 將這些規則置於程序中，讓個別公司能透過重寫應用程式所呼叫的程序來自訂垂直應用程式，而無需修改應用程式程式碼。 例如，訂單輸入應用程式可能會呼叫程序 InsertOrder ，參數數量固定; InsertOrder 的實作方式因公司而異。
可替換性 與將業務規則放入程序密切相關的是，程序可以在不重新編譯應用程式的情況下被替換。 若企業購買並安裝應用程式後，商業規則變更，公司可更改包含該規則的程序。 從申請的角度來看，情況並未改變;它仍然會呼叫特定的程序來完成特定任務。
DBMS 專用的 SQL 程序提供了一種方法，讓應用程式能夠利用DBMS專屬的SQL，同時保持互通性。 例如，在支援 SQL 中流程控制語句的資料庫管理系統程序，可能會捕捉並從錯誤中恢復，而在不支援流程控制語句的資料庫管理系統中，程序可能只是回傳錯誤。
程序在交易中依然存在 在某些資料來源中，當交易提交或回滾交易時，連線上所有預備的存取計畫都會被刪除。 透過將 SQL 陳述式置於程序中，程序會永久儲存在資料來源中，這些陳述式能夠在交易過程中存活下來。 程序在準備、部分準備或未準備狀態下的存活與否，視 DBMS 而定。
獨立發展 程序可以獨立於應用程式的其他部分開發。 在大型企業中，這可能成為進一步利用高度專業程式設計師技能的途徑。 換句話說，應用程式設計師可以撰寫使用者介面程式碼，資料庫程式設計師則可以撰寫程序。
程序通常用於垂直及客製化應用程式。 這些應用程式通常執行固定任務，且可在其中硬編碼程序呼叫。 例如，訂單輸入應用程式可能會呼叫 InsertOrder、 DeleteOrder、 UpdateOrder 和 GetOrders 這些程序。
從泛用應用程式呼叫程序的理由不多。 程序通常是為了在特定應用程式的情境下執行任務而撰寫，因此對一般應用程式沒有用處。 例如，試算表沒有理由呼叫剛才提到的 InsertOrder 程序。 此外，通用應用程式不應在執行時建構程序以期望更快的語句執行;這不僅可能比準備或直接執行慢，還需要DBMS專用的SQL語句。
例外是應用程式開發環境，這類環境通常提供程式設計師建立執行程序的 SQL 陳述式，並可能提供程式設計師測試程序的方式。 這類環境呼叫 SQLProcedures 來列出可用程序，並呼叫 SQLProcedureColumns 來列出輸入、輸入/輸出及輸出參數、程序回傳值，以及程序所建立的任何結果集的欄位。 然而，這類程序必須事先在每個資料來源上開發;這需要 DBMS 專用的 SQL 語句。
使用程序有三大主要缺點。 第一，必須為每個應用程式執行的資料庫系統撰寫並編譯程序。 雖然這對自訂應用程式來說不是問題，但對於設計支援多個資料庫管理系統（DBMS）的垂直應用程式，這會大幅增加開發與維護時間。
第二個缺點是許多資料庫管理系統不支援程序。 同樣地，這對於設計同時執行多個資料庫管理系統（DBMS）的垂直應用程式來說，最有可能成為問題。 為了判斷程序是否支援，應用程式會呼叫 SQLGetInfo 並啟用 SQL_PROCEDURES 選項。
第三個缺點，尤其適用於應用程式開發環境，是 ODBC 並未定義用於建立程序的標準文法。 換言之，雖然應用程式可以互通地呼叫程序，但無法互通地建立程序。