為何每個 Mythex 應用程式都有自己的資料庫

當你在 Mythex 上建構的應用程式需要儲存資料——註冊、預約、訂單——Mythex 會替該專案提供它自己的 Postgres 資料庫。不是共用資料庫中的一張表，也不是與別人並排的一個結構描述（schema）：而是一個獨立的資料庫，按需建立，無人使用時便會休眠。以下說明我們為何這樣建構，以及它的代價。

你會得到什麼

當你要求資料（「儲存候補名單電郵」、「儲存預約」）或使用 /database 指令時，Mythex 會：

• 為專案建立專用的 Postgres 資料庫（目前為 Postgres 17），
• 把連線資料以環境變數的形式注入你的工作區和已發佈的應用程式，因此它們永遠不會出現在你的程式碼中，並且
• 讓代理替你建立資料表，以及讀寫資料。

即時預覽和已發佈的應用程式使用的是同一個資料庫。它閒置五分鐘後會休眠，並在下一次查詢時喚醒。新的資料庫起初規模很小，負載增加時可以擴展，並設有上限，因此失控的查詢不會無限制地增長。詳情見資料庫文件。

為何不用一個大型共用資料庫？

共用資料庫中加入一欄，標明每列屬於哪個應用程式，會比較便宜，操作也較簡單。我們不採用這個做法，原因有四。

1. 無需信任的隔離

AI 撰寫的程式碼會出錯。在共用資料庫中，某個應用程式的一條查詢如果漏掉了 WHERE app_id = …，就可能讀取或覆寫另一位客戶的資料。而採用每個應用程式一個資料庫，便沒有其他客戶的資料可以觸及——錯誤會留在它自己的應用程式之內。

2. 它是真正的 Postgres，而不是專有的一層

你的應用程式以一般的 Postgres 連線字串與資料庫溝通。任何與 Postgres 配合的函式庫、ORM 或工具，在這裡都能運作。如果你匯出專案到別處運行，它期望的是 Postgres 資料庫——每個託管服務商都提供的東西——而不是 Mythex 專有的 API。

3. 每個應用程式可以依其所需而塑造

一個應用程式需要一張 bookings 表，並對時段設定唯一約束；另一個則需要對產品進行全文搜尋。有了自己的資料庫，每個應用程式的結構描述與遷移都由它自己負責，無需遷就一個最低公分母的設計。

4. 成本跟隨用量

由於每個資料庫各自休眠，沒有人使用的應用程式幾乎零成本，而繁忙應用程式的成本會以其自己的一行顯示。已發佈的資料庫用量，是根據資料庫實際量得的數據計費——這種計費方式如何運作。

取捨

這個設計並非沒有代價：

• 冷啟動。 休眠的資料庫在一段安靜時間之後的第一次查詢時，需要一點時間才能喚醒。對大多數應用程式來說幾乎察覺不到；但對於必須隨時即時回應的應用程式，這就需要考慮。
• 保持喚醒的成本。 只要有東西在查詢，資料庫就會保持喚醒。一個每隔幾秒就輪詢資料庫的應用程式，會全天候令它保持喚醒，費用比按需查詢的應用程式更高。如果你的用量比預期高，通常就是這個原因——請要求 AI 停止輪詢，改為在需要時才載入資料。
• 我們這一方要承擔更多運作。 建立、追蹤和清理數以千計的資料庫，比管理一個要多得多。這是我們的責任，不是你的。

如果你對資料庫還不熟悉

資料庫是應用程式保存需要記住的東西的地方。如果這個概念對你來說是新的，可以先看什麼是資料庫和什麼是 Postgres。當你準備好建構一個需要儲存資料的東西時，如何用 AI 建構應用程式會逐步說明如何加入它。