データベースの Primary Key （の少なくとも一部）をアプリケーションが生成した UUID にすると、冪等性のある API を設計しやすい。
例えば、iOS アプリからリソース生成リクエストが重複して行われることはよくある。リトライの仕組みを実装しなくてもボタンの重複タップを UI 側で完全に制御することは難しい。古い端末ではどうしても画面描画は遅くなるので、重複タップを画面描画でコントロールしていると間に合わなかったりする。このリソースにユニークな ID （相当の値）がなければサーバー・データベース側で冪等性を確保することはできない。こういったときに、リクエスト発行元である iOS アプリで生成した UUID をリソースに含めると冪等性は簡単に確保できる。ユニーク制約に従ってエラーになるからである。
上記の例以外でも、マイクロサービス化によってアプリケーションの外側にあるプロキシ（セットアップする開発者は別）から冪等性を前提にしたリトライが行われることもある。こういう考えにたつと、基本的にすべてのリソースで一律に UUID を使うようにするのは、漏れなく冪等性を維持しやすいというメリットがある。
また、そもそも分散環境を前提としたデータベースや将来的にそこへの移行を視野に入れる場合は、 Auto Increment は使えない。例えば Cloud Spanner では PK にインクリメンタルな値を使うことはホットスポットを避けるためとして推奨されていない。UUID が推奨されている。サービス初期は分散環境で動かす必要はないとしても、将来的なスケールを考えると最初から PK を UUID にしてアプリケーションを実装しておいた方が手戻りが少ない。
メモ。個人的には、Auto Increment という値の特性に依存するアプリケーション設計を避けることは可能だと思いつつ、Auto Increment のメリットとの兼ね合いで最終的に考える必要はある。