如果「可序列化」交易隔離層級用於所有寫入和所有需要一致資料檢視的讀取，則無需其他努力即可確保一致性。來自其他環境且編寫為使用可序列化交易以確保一致性的軟體，在這方面應在 PostgreSQL 中「直接運作」。

使用此技術時，如果應用程式軟體透過一個框架自動重試因序列化失敗而回滾的交易，則可以避免為應用程式程式設計師帶來不必要的負擔。將 default_transaction_isolation 設定為 serializable 可能是一個好主意。明智的做法是採取一些行動，以確保不會透過觸發器中的交易隔離層級檢查來無意或顛覆完整性檢查地使用任何其他交易隔離層級。

有關效能建議，請參閱第 13.2.3 節。

當非序列化的寫入是可能發生的情況下，為了確保目前列的有效性並防止其同時被更新，必須使用 SELECT FOR UPDATE、SELECT FOR SHARE 或適當的 LOCK TABLE 陳述式。（SELECT FOR UPDATE 和 SELECT FOR SHARE 僅鎖定傳回的列以防止同時更新，而 LOCK TABLE 鎖定整個資料表。）從其他環境將應用程式移植到 PostgreSQL 時，應考慮到這一點。

另外，從其他環境轉換過來的人員要注意的是，SELECT FOR UPDATE 並不保證同時進行的交易不會更新或刪除選定的列。 要在 PostgreSQL 中執行此操作，您實際上必須更新該列，即使不需要變更任何值。SELECT FOR UPDATE 暫時阻止其他交易取得相同的鎖定或執行會影響鎖定列的 UPDATE 或 DELETE，但是一旦持有此鎖定的交易提交或回滾，則除非在持有鎖定時實際執行了列的 UPDATE，否則被阻止的交易將繼續執行衝突的操作。

在非序列化的情況下，全域有效性檢查需要額外的思考MVCC。例如，銀行應用程式可能希望檢查一個資料表中所有貸項的總和是否等於另一個資料表中借項的總和，而這兩個資料表都在積極更新中。 比較兩個連續 SELECT sum(...) 命令的結果在讀取已提交模式 (Read Committed) 下無法可靠運作，因為第二個查詢很可能包含第一個查詢未計算在內的交易結果。 在單個可重複讀取 (Repeatable Read) 交易中執行這兩個總和運算將僅準確顯示在可重複讀取交易開始之前提交的交易的影響 — 但是人們可能會合理地懷疑，在交付答案時它是否仍然相關。 如果可重複讀取交易本身在嘗試進行一致性檢查之前應用了一些變更，則檢查的用處甚至變得更值得商榷，因為現在它包含了一些但並非所有交易開始後的變更。 在這種情況下，謹慎的人可能希望鎖定檢查所需的所有資料表，以便獲得對當前實際情況的無可爭辯的理解。 SHARE 模式（或更高）鎖定保證鎖定資料表中沒有未提交的變更，除了當前交易的變更之外。

另請注意，如果依賴明確鎖定來防止同時變更，則應使用讀取已提交模式 (Read Committed)，或者在可重複讀取模式 (Repeatable Read) 下，在執行查詢之前務必取得鎖定。 可重複讀取交易取得的鎖定可保證沒有其他修改資料表的交易仍在執行，但是如果交易看到的快照早於取得鎖定，則它可能早於資料表中的某些現在已提交的變更。 可重複讀取交易的快照實際上在其第一個查詢或資料修改命令（SELECT、INSERT、UPDATE、DELETE 或 MERGE）開始時凍結，因此可以在快照凍結之前明確取得鎖定。