按實際用量為資料庫計費
每個需要儲存資料的 Mythex 應用程式，都會有自己的 Postgres 資料庫，而已發佈應用程式的資料庫用量，會從與建立功能相同的額度餘額中扣除。直至 9 月下旬為止，我們都是根據應用程式伺服器的運行時間來估算這項用量。結果發現這個估算的錯誤足以產生影響，因此我們將它取代：現在每個資料庫都根據其供應商實際量度到的運算量計費，以一個已完成的小時為單位，而且每個小時只可能被收費一次。
資料庫如何運作
每個資料庫都運行在會縮減至零的無伺服器 Postgres 上：閒置幾分鐘後會進入休眠，並在下一次查詢時喚醒。喚醒期間，它可以隨負載上下調整運算資源。這正是「每個應用程式一個資料庫」得以負擔得起的原因：大多數應用程式大部分時間都很安靜，而休眠中的資料庫幾乎沒有成本。
這也意味著資料庫的成本取決於兩件我們從外部看不見的事：它醒著的時間有多長，以及醒著的時候規模有多大。
原本的估算哪裡出錯
我們最初的計量表有一個假設：已發佈應用程式的伺服器每運行一個小時，就按最小的運算規模收取一小時的資料庫費用。
這在三方面都有錯誤：
- 規模有誤。 資料庫實際上是以比估算所假設的更大的預設規模運行。
- 資料庫會自動調整規模。 在負載下，它們會擴大，而估算從未考慮到這一點。
- 資料庫並非跟隨應用程式伺服器運作。 只要任何東西查詢它，資料庫就會保持清醒，無論是應用程式、排程工作，還是輪詢它的腳本，而不論應用程式伺服器是否在運行。
最終的結果是：估算向用戶收取的費用，大約只有資料庫實際成本的一半。這對我們來說是不可持續的，而且也令應用程式中顯示的用量數字，與人們理解的意思不符。
以量度取代猜測
我們的資料庫供應商會回報每個專案每小時的運算單位秒數，即它實際使用了多少運算資源，包括規模在內。因此，計量表現在的運作方式如下：
- 對於每個帶有資料庫的已發佈應用程式，取得自應用程式上線以來，每一個已完成小時的實測用量。
- 按供應商的價格將該用量換算為成本，套用方案的費率，然後從應用程式擁有者的額度中扣除。
- 每次最多回溯一天，因此在我們的 API 重新啟動期間遺漏的小時，之後仍會被計費。
儲存則另外按大小計費，因為它不取決於活動量。
絕不重複收取同一小時的費用
一個在多部伺服器上運行、而且可能崩潰並重試的計費計量器，必須小心避免重複收費。每個資料庫的每一小時，都會在收費之前，先在其自身的資料庫列中被認領，並對（資料庫、小時）這一組合設有唯一性限制。如果兩部伺服器，或者一次重試，嘗試為同一小時計費，就只有一次認領會成功。
對於罕見的故障情況，我們也作出了刻意的選擇：如果程序在認領某小時之後、收費之前崩潰，該小時會保持已認領且未計費的狀態。在罕見的崩潰中損失一小部分收入，好過向任何人重複收費。
而且在實測計費開始運作時，它是從下一個完整的小時開始。之前的小時已經按舊的估算收費，如果再根據實測數據計費，那段時間就會被收費兩次。
如果你在 Mythex 上建立應用程式，這代表什麼
- 你的資料庫帳單現在反映的是你的資料庫實際做了什麼。 很少使用的應用程式成本很低；不斷查詢其資料庫的應用程式，會令資料庫保持清醒，費用也會更高。
- 最大的影響因素是你的應用程式如何使用資料庫。 每隔幾秒輪詢資料庫，會令它全天候保持清醒。改為按需要由 AI 擷取資料，或將資料快取起來，就可以讓資料庫進入休眠。我們的資料庫是什麼指南涵蓋了基本知識。
- Pro 方案的託管、資料庫和儲存費率，是 Free 方案費率的一半。詳情請參閱額度文件。
我們從中學到的
- 按用量計費的成本估算會偏離實際。 當上游供應商能告訴你實際用了多少時，就應該以此計費。
- 在你收費的最小單位上令計費具備冪等性。 對我們而言，就是每一個資料庫小時。
- 當你必須失敗時，失敗時要有利於客戶。