open AI 的業務大部分都是來自於讀的請求，那些使用者的歷史紀錄或是提示詞都是需要被記錄在資料庫裡面的，當前做法是會有一個主資料庫（PostgreSQL) 專門處理寫入的部分，另外會有約 50+ 的資料庫負責讀取的部分來做到讀寫分離。
在資料庫擴展上 Open AI 同時採用了 scale up 跟 scale out 的方式， scale up 他們直接使用銀彈方案，升級到 Azure 的最高級資料庫， scale out 其中又有 sharding 和 replication，但是 Open AI 主要寫入的 PostgreSQL 並沒有使用 sharding，而 replication 則是用在了那些純讀取的資料庫來分散主資料庫的讀取壓力。
雖然說 Open AI 的業務場景是讀取大於寫入，但是在這個全球使用的產品下，寫入的流量也是相當的可觀，因此在這個挑戰下也是做了幾項優化
前面提到他們因當前的業務考量因此沒有做寫入 PostgreSQL sharding 但是在一些新功能，則是將資料寫到了 CosmosDB 做 sharding，另外對於一些並不需需要及時寫入的資料則採取了延遲寫入避免在高峰時期寫入資料庫。
寫入的主資料庫在某些情境下也是會需要用到讀取查詢，在分析下 Open AI 針對了成本高的查詢做裡查詢最佳化
首先是 OLTP 以及 OLAP 分清楚使用場景，避免在 OLTP 做大量的 table join，另外也不過度依賴 ORM，確認 ORM 出來的 raw sql 的查詢成本，另外利用了 PostgreSQL 的 idle_in_transaction_session_timeout 來清理閒置的查詢
不過在這個只有單一節點的寫入架構中，最擔心的就是主資料庫的單點故障，於是乎他們利用了 Azure 所提供的 hot standby(熱備份)，當寫入資料庫掛掉時可以切換到備份的資料庫
最後在新功能上線時，為確保那些新功能的請求，並不會造成重要舊功能的 API loading, 因此在那先新功能上，為避免 SQL 還沒優化或是一時之間的大量使用者造成 loading, 於是他們將重要的舊功能與新功能根據導向不同的優先度實例，避免低優先度的功能影響到高優先度功能的使用