產品筆記
靜靜擴充的資料庫
使用者越來越多，是件好事。但現有資料庫還能支撐多久，也逐漸成為問題。Authrim 會在需要之前為新帳戶準備好儲存空間，讓服務成長不必從資料搬遷開始。
先增加存放位置，再考慮搬遷
Authrim使用的Cloudflare D1對單個資料庫有容量上限：免費方案500 MB，付費方案10 GB。隨著使用者和資料成長，最終會需要新的存放位置。
Authrim從一開始就支援把帳戶分配到多個資料庫，因此擴容時不必搬遷所有已有帳戶。這裡把每個儲存單元稱為分片（shard）。
已有帳戶留在原處，為新帳戶增加存放位置。這就是帳戶儲存擴展的基本方式。
不同資料，成長速度也不同
租戶設定（例如OAuth客戶端和策略）、帳戶與個人資料、透過電子郵件查找帳戶位置的索引，在Authrim中分別儲存。
使用者增加不代表所有資料庫都要一起擴容。帳戶儲存與查找索引的記錄數量和成長速度不同，只需為有需要的部分增加容量。
關注剩餘的帳戶名額
新帳戶會被分配到租戶可用的分片。系統優先選擇運作正常、已分配數量相對目標數量較低的分片。
判斷依據不是磁碟使用率，而是距離設定的目標帳戶數還剩多少名額。例如目標為10萬帳戶時，剩餘2萬的餘量可以作為準備下一處儲存的參考。
可用分片餘量較小時，系統會分配已準備好的備用分片。多個租戶共用的共享型，以及一個租戶獨享的專用型，都採用這一思路。
共享租戶
專用租戶
共享與專用混合
日常維運中，不必再重複做什麼
設定自動佈建後，註冊量每次成長時，工作人員不必再手動建立資料庫、準備表結構並連接新註冊位置。每次增加容量，也不必為已有帳戶制定搬遷計劃。
工作人員主要確認擴容進度、失敗情況，以及使用量和費用是否符合預期。權限不足或服務上限仍需人工處理。在這種分工下，Authrim負責準備下一個存放位置。
只看今天的空位還不夠
同樣剩餘2萬個名額，每天新增100個帳戶和每小時新增1萬個帳戶，準備時間完全不同。
Authrim結合目前分配數量與近期註冊速度，預測帳戶儲存和查找索引的容量需求。排程工作每分鐘執行，分配帳戶後也會更新帳戶預測。
計算需求時，會計入正在建立的分片，避免多個流程發現同一次容量不足後，各自重複建立資料庫。
從建立到投入使用
備用分片不足時，Authrim透過Cloudflare管理API建立D1，準備表結構、設定Worker存取並分發儲存位置。讀寫檢查通過後，才把資料庫投入分配。
自動執行需要啟用自動佈建，並分別設定D1與Workers的API權杖。無法自動執行時，工作人員可通過設定工具繼續操作。
建立進度會被保存。暫時通訊故障可以從該狀態重試；權限不足或資源上限則需要先解決原因，再繼續執行。
如果準備速度跟不上、註冊名額耗盡，新註冊可能需要重試。提前準備的目的就是減少這種等待。
是否搬遷資料，仍由維運人員決定
增加容量與移動已有資料是不同操作。例如，把租戶從共享分片遷往專用分片，不僅要新增位置，還要複製已有資料。
維運人員決定是否開始遷移。批准後，由Authrim執行同步、驗證與切換。
目前支援的佈局變更是共享轉專用。尚未實作專用轉共享，也不會自動把已有帳戶重新均勻分布。
刪除退役分片同樣需要人工批准。容量成長不會自動觸發已有資料的移動或刪除。
已經驗證到什麼程度
2026年7月使用20萬個測試帳戶測量時，Core約208 MB，PII約238 MB，Lookup約426 MB，分別不到付費方案單庫10 GB上限的5%。實際用量取決於儲存的屬性與索引。
每個分片的預設目標是10萬帳戶。系統保留準備下一個分片的餘量，而不是盡量填滿物理容量。
Authrim仍處於pre-1.0階段，長期、大規模正式環境的維運經驗還有待積累。20萬個測試帳戶的容量測量，不等同於數百萬人每天使用的正式環境實績。
讓成長少一些遷移計劃
小型服務不需要一開始就準備大型部署。可以從少量分片開始，隨著註冊成長增加位置。Authrim把所需準備和流程納入系統。
使用者開始成長時，不必先把資料庫搬遷列為首要任務。減少這些工作，才能把更多時間投入服務本身。
測量時間為2026年7月30日，使用20萬個測試帳戶。MB採用十進制單位。D1容量上限見Cloudflare文件。