為什麼每個 Mythex App 都有自己的資料庫

當你在 Mythex 上建置的 App 需要儲存資料——註冊、預約、訂單——Mythex 會為該專案提供 自己的 Postgres 資料庫。不是共用資料庫裡的一張表，也不是和別人的 schema 並排放在一起：而是一個獨立的資料庫，依需求建立，並在無人使用時休眠。以下是我們為何這樣設計，以及它的代價。

你會得到什麼

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

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

即時預覽與已發佈的 App 使用的是同一個資料庫。它在 閒置 5 分鐘後休眠，並在下一次查詢時喚醒。新的資料庫起步很小，可以在負載下擴充，並設有上限，因此失控的查詢不會無限制地成長。更多內容見資料庫文件。

為什麼不用一個大型的共用資料庫？

共用資料庫加上一個欄位標示每一列屬於哪個 App，執行成本較低，營運也較簡單。我們選擇不這樣做，原因有四個。

1. 不必信任的隔離

AI 寫的程式碼會犯錯。在共用資料庫中，某個 App 的查詢中少了一個 WHERE app_id = …，就可能讀取或覆寫另一位客戶的資料。使用每個 App 一個資料庫，就不會有其他客戶的資料觸及得到——一個 bug 會被困在它自己的 App 之內。

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

你的 App 使用標準的 Postgres 與一般的連線字串溝通。任何能與 Postgres 搭配的函式庫、ORM 或工具，在這裡都能運作。如果你匯出專案到其他地方執行，它預期的是 Postgres 資料庫——每個主機服務商都提供的東西——而不是 Mythex 專屬的 API。

3. 每個 App 都能依需要塑形

有一個 App 需要一張對時段有唯一性限制的 bookings 表；另一個則需要對產品做全文搜尋。有了自己的資料庫，每個 App 的 schema 與遷移都由它自己決定。沒有任何東西需要去符合一個最低公約數的設計。

4. 成本跟著使用量走

由於每個資料庫各自休眠，沒有人使用的 App 幾乎不花錢，而忙碌的 App 的成本會以它自己的一行呈現。已發佈的資料庫用量，是依資料庫實際測得的數值計費——計費方式。

取捨

這種設計並非沒有代價：

• 冷啟動。 休眠中的資料庫在安靜一段時間後的第一次查詢，需要一點時間才會喚醒。對大多數 App 來說幾乎感覺不到；但對於任何時段都必須立即回應的 App，這需要考量。
• 醒著時的閒置成本。 只要有東西在查詢，資料庫就會保持清醒。一個每隔幾秒就輪詢資料庫的 App，會讓它全天候保持清醒，成本比按需查詢的 App 更高。如果你的用量比預期高，通常就是這個原因——請要求 AI 停止輪詢，改為在需要時才載入資料。
• 我們這邊的運作零件更多。 建立、追蹤與清理數千個資料庫，比管理一個要麻煩得多。這是我們要承擔的問題，不是你的。

如果你對資料庫還不熟悉

資料庫是 App 保存它需要記住的東西的地方。如果這個概念對你來說是新的，可以從什麼是資料庫與什麼是 Postgres開始。當你準備好建置會儲存資料的東西時，如何用 AI 建置 App 會逐步說明如何加入資料庫。