在現代 SaaS 服務整合過程中，越來越多團隊會選擇像 Clerk 這樣的雲端身份認證服務，讓註冊與登入流程更快導入。不過，這帶來了一個很常見但容易被低估的資料庫設計問題——「身分主鍵型別不一致」。
以我們最近協助某客戶導入 Clerk + Neon（Postgres 雲端服務）的經驗來說：
- Clerk 的 User ID（Clerk ID）預設是一組字串（如 “user_xxxxxxxxx"），並非 UUID。
- 而現有的 Postgres 用戶資料表（users）設計時，User ID（主鍵）是 UUID 型別，並預設自動產生。
客戶需求轉變
原本客戶在 Clerk 與資料庫間分別各自維護一組 ID（Clerk ID 字串 & Postgres UUID），雙方以「對應欄位」關聯。但為了簡化資料同步，現在希望以 Clerk ID 直接作為 Postgres 的 users 主鍵，只要管理一個 ID。
這就涉及一連串「破壞式」資料庫 schema 變更：
- 所有關聯到 users.id 的外鍵 constraint 都必須先移除。
- 將 users.id 欄位由 UUID 轉為 VARCHAR(255) 或 TEXT，並指定 PRIMARY KEY。
- 更新所有參照表（Reference Table）中的欄位型別為字串。
- 重新加回外鍵約束。
這個過程會有明顯停機風險，且資料越大、連動越多，越容易出現邊際效應或潛在 bug。此外，一旦轉為字串，若未來要換回 UUID（例如不用 Clerk 時），會更難無痛回頭。
UUID vs. 字串主鍵的效能影響
- UUID（原生型別）：
- 儲存空間小（16 bytes），索引快，比較是 binary。
- index 可裝更多資料，I/O 較少。
- 字串（TEXT/VARCHAR）：
- 字串形式需 36 bytes 以上，index 大幅增加，效能下降。
- 比較為逐字元，遇到大量 join、查詢時更慢。
- 若只用字串 id，設計錯誤或日後需求變動彈性低。
Clerk 官方的 Neon 教學範例直接用 id: string 當主鍵，這雖然可行，但其實對於成長型產品並不總是是最佳做法。
玖駿資訊如何協助
玖駿資訊在導入第三方認證（如 Clerk）、資料庫 Schema 改造，以及混合 ID 管理經驗豐富。我們會：
- 事前評估現有 Schema 與未來可擴充性：協助客戶釐清現有架構的約束，對比 Clerk Id 與 UUID 主鍵各自的優缺點，並量身訂製轉換/兼容方案。
- 提供無痛過渡設計：建議「雙軌制」暫存，讓 Clerk Id 先以欄位同步（非主鍵），未來有完整測試、驗證後再考慮主鍵轉換，避免一次到位的破壞式更動帶來營運風險。
- 資料庫變更腳本設計 & 測試：設計原子化 migration script，並配合腳本化的回滾方案，確保轉換過程安全、可預期。
玖駿資訊股份有限公司 