跳至主要內容

Prisma Postgres 常見問題

關於 Prisma Postgres 的運作方式、查詢計費方式以及它如何與 Prisma ORM 整合的常見問題。

一般資訊​

我可以在不使用 Prisma ORM 的情況下使用 Prisma Postgres 嗎？​

可以，您可以透過直接連線 (direct connection)，將 Prisma Postgres 與任何資料庫程式庫或工具搭配使用。

如何從 GitHub 登入切換為電子郵件與密碼登入？​

如果您之前使用 GitHub 註冊，現在想改為使用電子郵件與密碼登入，請依照下列步驟操作：

  1. 驗證您的 GitHub 電子郵件地址
    • 確認您 GitHub 帳號關聯的主要電子郵件地址（例如從您的 GitHub 個人資料或通知設定中查看）。
  2. 建立新的電子郵件/密碼帳號
    • 前往電子郵件/密碼註冊頁面。
    • 使用與您 GitHub 帳號連結的相同電子郵件地址來建立新帳號。
    • 我們的系統會自動將您新的電子郵件/密碼帳號連結到您現有的資料。
  3. 測試您的登入
    • 登出後，嘗試使用您的電子郵件與剛建立的密碼登入。

如果您遇到任何問題，請聯繫我們的支援團隊協助連結您的帳號。

VS Code 無法識別 $extends 方法​

如果您將 Accelerate 的 Prisma Client 擴充功能新增至 VS Code 中目前開啟的現有專案，編輯器可能無法立即識別 $extends 方法。

這可能是 TypeScript 伺服器尚未識別重新生成的 Prisma Client 的問題。要解決此問題，您需要重新啟動 TypeScript。

  1. 在 VS Code 中，開啟命令面板 (Command Palette)。您可以按下 F1 或選擇 檢視 (View) > 命令面板 (Command Palette) 來開啟。
  2. 輸入 typescript，然後選擇並執行 TypeScript: Restart TS server 指令。

現在 VS Code 應該就能識別 $extends 方法了。

Prisma Postgres 在哪些區域可以使用？​

Prisma Postgres 目前在下列區域提供服務：

區域代碼地點
us-west-1舊金山 (San Francisco)
us-east-1北維吉尼亞 (North Virginia)
eu-west-3巴黎 (Paris)
eu-central-1法蘭克福 (Frankfurt)
ap-northeast-1東京 (Tokyo)
ap-southeast-1新加坡 (Singapore)

我們正持續努力擴展區域支援。如果您想請求特定區域，請透過 Discord 與我們聯繫。

定價​

Prisma Postgres 根據所消耗的操作 (operations) 和儲存空間 (storage) 進行計費。請參閱 定價頁面 以取得詳情，並查看我們的 部落格文章 以深入了解「操作」的定義以及此定價模式的運作方式。

什麼是「操作」？​

每當您與資料庫進行互動時，就會計算為一次操作。無論是讀取、寫入、簡單或複雜的操作，皆計為一次。

一個操作可以是：

  • 一個 Prisma ORM 查詢（當使用 Prisma ORM 時）
  • 一個 SQL 查詢（當使用 直接 TCP 連線 時）

Prisma Postgres 的查詢執行時間會影響定價嗎？​

不會，Prisma Postgres 的費用僅基於操作次數，而非執行這些操作所需的運算資源。

無論查詢執行時間是 10 毫秒還是 10 秒，其對定價的影響都相同。

使用 Prisma ORM 和直接 TCP 連線之間的定價有何不同？​

基於操作的定價原則對於 Prisma ORM 和 直接 TCP 連線 是一樣的。然而，根據您是使用 Prisma ORM 還是直接 SQL 與資料庫互動，操作的定義略有不同：

  • 使用 Prisma ORM 時：透過 Prisma Client 發送的查詢（例如 prisma.user.findMany()）
  • 使用其他工具時：透過直接連線發送的 SQL 查詢（例如 SELECT * from "User"）

請注意，單一 Prisma ORM 查詢可能會轉換成多個 SQL 查詢，這可能使 Prisma ORM 比直接 SQL 更具經濟效益。

讀取和寫入查詢的費用相同嗎？​

是的，讀取和寫入查詢同樣計為操作，並以相同方式計費。

SELECT 1 查詢算作可計費操作嗎？​

是的，像 SELECT 1 這樣的查詢會被算作一次操作，並會據此計費（即使該查詢並未存取任何實際資料）。

我該如何在 Prisma ORM 中估算操作次數？​

您可以透過整合 Prometheus 等應用程式效能監控工具，來估算您在 Prisma ORM 中的操作用量。

我可以使用哪些策略來優化每次操作的成本？​

Prisma Postgres 按操作計費。您在單次操作中完成的事情越多，費用就越低。以下是減少操作次數的一些技巧：

  • 批次寫入 (Batch your writes)：使用 createMany、updateMany 或 deleteMany，而不是對單列呼叫進行迴圈處理。

    // One operation, three users
    await prisma.user.createMany({
      data: [
        { name: 'Alice' },
        { name: 'Bob'   },
        { name: 'Carol' },
      ],
    })

  • 使用巢狀關聯輔助工具：例如 connectOrCreate 或 set，在單次操作中建立或連結相關記錄。

    // Post and (if needed) its author, all in one request
    await prisma.post.create({
      data: {
        title: 'Hello World',
        author: {
          connectOrCreate: {
            where:  { email: 'alice@example.com' },
            create: { name: 'Alice', email: 'alice@example.com' },
          },
        },
      },
    })

  • 在個別查詢彼此不相依時，優先使用一般 (陣列) 交易 (transactions) 而非 互動式交易 (interactive transactions)。

    // Interactive transaction: counted as 2 operations
    await prisma.$transaction(async (tx) => {
      await tx.user.create({ data: { name: 'Alice' } })
      await tx.post.create({ data: { title: 'Hello', authorId: 1 } })
    })

    // Array transaction: counted as 1 operation
    await prisma.$transaction([
      prisma.user.create({ data: { name: 'Alice' } }),
      prisma.post.create({ data: { title: 'Hello', authorId: 1 } }),
    ])

如果後續的查詢需要先前的查詢結果（例如，您需要剛建立的使用者 ID），則為了正確性應堅持使用互動式交易。否則，批次處理和陣列交易可以讓您將多個查詢合併為單一計費操作，從而降低操作次數並節省成本。

是否有範例工作負載可用於估算預期費用？​

我們將展示三個範例工作負載，並估算小型、中型和大型工作負載的費用。每個範例都結合了合理的每月活躍使用者數 (MAU)、典型的每日使用者活動量以及整數的儲存需求。

我們將使用下列公式來估算每月費用：

total_ops            = MAUs x actions_per_user_per_day x 30      
billable_ops         = total_ops - included_ops_for_plan
ops_cost             = (billable_ops ÷ 1_000_000) x plan_rate

billable_storage_GB  = storage_used_GB - free_storage_for_plan
storage_cost         = billable_storage_GB x storage_rate_for_plan

total_monthly_cost   = ops_cost + storage_cost + base_plan_fee
注意

您可以使用自己的 MAU 數量、活動等級和儲存用量，利用上述公式來預估任何方案的成本。

我們會將每個工作負載與付費方案及其對應的定價細節關聯起來，例如小型工作負載對應 Starter 方案、中型對應 Pro 方案、大型對應 Business 方案。然後，我們將公式應用於這些範例，以產生粗略的每月費用估算。例如：

定價詳情

以下是各定價方案的細節：

  • Starter 方案 - 每百萬次操作 $8
    • 基礎方案費用 - 每月 $10
    • 包含操作數 - 1,000,000
    • 儲存空間 - 10 GB 免費，超過後每 GB $2
  • Pro 方案 - 每百萬次操作 $2
    • 基礎方案費用 - 每月 $49.00
    • 包含操作數 - 10,000,000
    • 儲存空間 - 50 GB 免費，超過後每 GB $1.5
  • Business 方案 - 每百萬次操作 $1
    • 基礎方案費用 - 每月 $129.00
    • 包含操作數 - 50,000,000
    • 儲存空間 - 100 GB 免費，超過後每 GB $1

我們也有「免費方案 (Free plan)」，但在下列計算中不予考慮，因為它僅供評估使用，不適用於生產環境的工作負載。您也可以在 定價頁面 上了解各方案的詳細定價資訊。

Starter 方案的小型工作負載範例:

一個 MAU 約 500 的業餘愛好或早期專案。每位使用者每天執行約 10 次動作，整個資料庫使用約 0.5 GB 儲存空間。根據這些假設，您可以使用下列公式計算每月費用：

  • total_ops = 500 x 10 x 30 = 150000
  • billable_ops = 0 (150,000 次操作低於 100 萬次免費操作)
  • ops_cost = $0
  • storage_cost = $0 (0.5 GB 低於已包含的 10 GB 儲存空間)
  • base_plan_fee = $10

total_monthly_cost = 每月 $10.00

Pro 方案的中型工作負載範例:

一個服務約 5000 MAU 的成長中 SaaS 產品。重度使用者平均每天執行約 40 次動作，應用程式儲存約 6 GB 資料。根據這些假設，您可以使用下列公式計算每月費用：

  • total_ops = 5000 x 40 x 30 = 6000000
  • billable_ops = 0 (600 萬次操作低於 1000 萬次免費操作)
  • ops_cost = $0
  • storage_cost = $0 (6 GB 低於已包含的 50 GB 儲存空間)
  • base_plan_fee = $49.00

total_monthly_cost = 每月 $49.00

Business 方案的大型工作負載範例:

一個處理約 50000 MAU 的生產級消費性應用程式。每位使用者每天約 60 次動作的高頻率使用量帶來了顯著流量，資料集達到約 40 GB。根據這些假設，您可以使用下列公式計算每月費用：

  • total_ops = 50000 x 60 x 30 = 90000000
  • billable_ops = 90000000 - 50000000 = 40000000
  • ops_cost = (40000000 ÷ 1000000) = 40.00 x $1 = $40.00
  • storage_cost = $0.00 (40 GB 低於已包含的 100 GB 儲存空間)
  • base_plan_fee = $129.00

total_monthly_cost = $40.00 + $129.00 = 每月 $169.00

快取操作 (Cached operations) 的計費方式相同嗎？​

每個請求，無論是命中資料庫還是從快取服務，都算作一次操作。Prisma Postgres 採用統一的「每操作」定價，且從不針對出口流量 (egress traffic) 收費，因此快取回應不會產生任何額外費用，也不會減免費用。這種統一費率使計費模式可預測，並避免了按請求計費的複雜性。

如果我透過 Vercel 使用 Prisma Postgres，該如何升級我的方案？​

若要透過 Vercel 升級方案，請依照下列步驟操作：

  • 開啟您的 Vercel 儀表板。
  • 前往您 Vercel Team 中的 Integrations 分頁。
  • 點擊 Prisma Integration 上的 Manage。
  • 導覽至 Settings 分頁。
  • 在 Current Installation Plan Level 下，點擊 Change Plan。
  • 選擇您要升級的方案。

快取 (Caching)​

Prisma Postgres 內建連線池 (connection pooling) 和全域快取 (global caching)。這些功能透過優化查詢的路由與快取方式來提升效能。

Prisma Postgres 的快取層如何知道要從哪個區域擷取快取？​

底層上，Prisma Postgres 的快取層使用 Cloudflare，後者使用 Anycast 進行網路定址與路由。傳入的請求將被路由至其網路中距離最近且具備效率處理能力的資料中心或「節點」。若要深入了解其運作方式，我們建議研究 Anycast。

我該如何讓 Prisma Postgres 的快取失效？​

如果您使用 付費方案，可以透過 $accelerate.invalidate API 按需讓快取失效；或者您也可以以專案為單位，每天最多失效整個快取五次。此限制依據 您的方案 而定。您可以透過 Accelerate 設定頁面管理此設定。

Prisma Postgres 快取層的一致性模型是什麼？​

Prisma Postgres 中的快取層沒有一致性模型。它並非一個需要節點達成共識的分散式系統（因為資料僅儲存在距離使用者最近的快取節點中）。然而，儲存在 Prisma Postgres 快取節點中的資料不會傳播到其他節點，因此快取層在設計上不需要一致性模型。

Prisma Postgres 實作了 read-through 快取策略，特別適用於讀取密集型的工作負載。

快取所提供資料的新鮮度取決於您在查詢中定義的快取策略。請參閱 此章節 以取得關於選擇正確查詢快取策略的更多資訊。

Prisma Postgres 的快取層與其他快取工具（例如 Redis）有何不同？​

Prisma Postgres 的快取層：

  • 是一個專業的快取，允許您使用快取策略在程式碼層面優化資料存取。另一方面，像 Redis 和 Memcached 等工具則是通用型快取，旨在具備適應性與靈活性。
  • 是一個託管服務，減少了建立與維護快取服務的時間、風險及工程工作量。
  • 預設為全域分散式，減少了查詢延遲。其他快取工具則需要額外的設定才能在全球範圍內提供服務。

我什麼時候不應該使用 Prisma Postgres 的快取功能？​

Prisma Postgres 的快取層是一個全域資料快取與連線池，讓您能在程式碼層面優化資料存取。雖然使用 Prisma Postgres 快取可以顯著提升應用程式效能，但它並不總是適用於您的所有使用場景。

若符合以下情況，此全域快取功能可能不適合您的應用程式：

  • 您的應用程式僅在特定區域內使用，且您的應用程式伺服器與資料庫都位於同一區域的同一網路中。例如，如果應用程式伺服器與資料庫在同一區域和網路中，資料庫查詢通常會快得多。然而，如果您的應用程式伺服器與資料庫位於不同區域或網路，快取節點將加速您的查詢，因為資料會快取在距離您應用程式最近的資料中心。

  • 您的應用程式資料在每次檢索時都必須保持最新，導致難以建立合理的快取策略。

配置 cacheStrategy 時，ttl 參數允許的最大值是多少？​

存活時間 (Time-to-live) (ttl) 參數最多可設定為一年。然而，請注意，如果快取中的項目未被頻繁存取，它們可能會被驅逐 (evicted)。

根據我們的實驗，我們觀察到快取項目通常會保留約 18 小時。雖然如果項目被積極存取，它們可能會在快取中停留更久，但這並不保證。

注意

即使是經常存取的項目也可能偶爾從快取中被驅逐。無論活動頻率如何，項目幾乎不可能存留一個月或更長時間。

為什麼我偶爾會看到非預期的快取行為？​

Prisma Postgres 的快取層在觀察到專案的高負載時表現最佳。許多快取操作（如提交資料至快取及更新過期資料）都是非同步發生的。進行快取層基準測試時，我們建議使用迴圈或負載測試方式。這能更好地模擬高負載情境，並減少低頻操作帶來的異常值。

Prisma 操作透過 HTTP 發送到 Prisma Postgres。因此，對 Prisma Postgres 的第一次請求必須建立 HTTP 握手，並可能因此產生額外的延遲。我們正在探索未來減少此初始請求延遲的方法。

Prisma Postgres 的快取節點在哪些區域提供？​

Prisma Postgres 的快取層運行在 Cloudflare 的網路上，快取命中由 Cloudflare 的 300 多個節點服務。您可以在此找到 Prisma Postgres 快取節點可用的區域：https://www.cloudflare.com/network/。

讓快取查詢結果失效需要多久時間？​

由於快取需要在全域範圍內清除，很難提供確切的時間範圍。不過，快取資料具有最終一致性，通常會在幾秒鐘內傳播到所有的 PoP（存取點）。在極少數情況下，可能需要更長的時間。

這裡有一個 示範應用程式，您可以測試快取查詢結果失效所需的時間。

Invalidate (失效) 與 Revalidate (重新驗證) 有何區別？​

Invalidate (失效)：快取項目被刪除，下一次請求時會擷取新資料，從而導致「快取未命中 (cache miss)」。這會移除過期資料，但在快取重新填充之前，回應可能會變慢。

Revalidate (重新驗證)：快取項目會主動更新，確保下一次請求使用來自快取的最新資料。這能保持快取有效，並透過避免「快取未命中」來維持更快的回應時間。

什麼是按需快取失效 (on-demand cache invalidation)？​

按需快取失效 允許應用程式在資料變更時立即更新特定的快取資料，而無需等待常規的快取重新整理週期。這能確保使用者的資訊準確且保持最新。

我什麼時候應該使用快取失效 API？​

當資料一致性無法等待快取的標準過期或重新驗證時，快取失效 API 是必需的。關鍵使用案例包括：

  • 內容更新：當發生重大變更（如發布文章的編輯、產品更新或個人資料修改）時，這些修改需要立即呈現。
  • 庫存管理：在即時應用程式（如庫存或預訂系統）中，庫存水準、可用性或預訂狀態必須反映最新資訊。
  • 高優先級資料：對於時間敏感的資料（如突發新聞或緊急通知），使用者必須能立即看到最新資訊。

在這些場景中使用按需快取失效，有助於僅重新整理必要的資料，從而保持系統效能，同時確保使用者取得準確、最新的資訊。

連線池 (Connection pooling)​

我可以增加 Prisma Postgres 執行個體的查詢持續時間和回應大小限制嗎？​

可以，您可以根據您的訂閱方案提高 Prisma Postgres 的限制。以下是可配置的限制：

限制免費版入門版Pro 方案Business 方案
查詢逾時最長 10 秒最長 10 秒最高 20 秒最高 60 秒
互動式交易逾時最長 15 秒最長 15 秒最高 30 秒最高 90 秒
回應大小最高 5 MB最高 5 MB最高 10 MB最高 20 MB

請參閱 定價頁面 以了解有關可用方案及其對應限制的更多詳情。

警告

雖然您可以根據訂閱方案增加這些限制，但仍建議您優化您的資料庫操作。在我們的疑難排解指南中了解更多。

查詢優化​

Prisma Postgres 允許透過 Prisma Optimize 進行查詢優化，並提供效能建議，幫助您在開發過程中改進資料庫查詢。您可以啟用它與 Prisma Postgres 搭配使用，或與您自己的資料庫一起使用，但設定和整合步驟有所不同。

您可以自動實作優化嗎？​

Prisma Postgres 的查詢優化功能提供關於如何改進資料庫查詢的見解與建議。它不會變更任何現有的查詢或您的 Prisma schema。

錄製階段 (recording session) 會保留多久？​

儲存保留期沒有限制。查詢效能錄製階段將會一直儲存，直到您明確刪除它為止。

建議上限會每月重置嗎？​

是的，建議使用量會在每個月初重置。例如，如果您在月底前使用了 5 條建議，您的使用量將在下月初重置為 0。

如果我在 Starter 方案中超過建議上限，會被收費嗎？​

是的，如果您使用的是 Starter 方案，在一個計費週期內超過 5 條建議，將會在該週期結束時產生 $5 的費用。如需更多資訊，請訪問 我們的定價頁面。

已檢視的 Prisma AI 建議是如何追蹤計費的？它們是根據產生的建議還是已檢視的建議來計算的？​

它們是根據「已檢視」的建議來計算的。一旦您點擊建議表格中的建議並查看詳細頁面，即算作一次檢視。

我可以在生產環境中啟用 Prisma Postgres 的查詢優化嗎？​

不可以，Prisma Postgres 的查詢優化功能不建議在生產環境中使用。它是專為本地開發設計的，在此階段提供有價值的見解與優化。雖然在技術上可以在生產環境中運行它，但這樣做可能會導致效能問題或非預期的行為，因為它並非為了處理生產環境工作負載的複雜性與規模而建。為了獲得最佳體驗，我們建議僅在開發環境中測試查詢優化。

您可以在 Client 擴充功能中使用 enable 屬性，以實現僅在開發環境中運行。預設情況下，enable 屬性設為 true。

script.ts
import { PrismaClient } from '@prisma/client'
import { withOptimize } from "@prisma/extension-optimize"

const prisma = new PrismaClient().$extends(
  withOptimize({
    apiKey: process.env.OPTIMIZE_API_KEY,
    enable: process.env.ENVIRONMENT === 'development',
  })
);

為什麼我會看到 "[optimize] HTTP 409 Conflict: There is no active recording to write queries to" 的警告？​

當 Prisma Optimize 收到查詢但沒有開啟錄製階段時，可能會出現此警告。通常，這發生在生產環境中不慎啟用 Prisma Optimize 時。Prisma Optimize 是專為本地開發環境設計的，不應在生產環境中啟用。若要避免此警告，請確保 Prisma Optimize 僅在開發期間運行。

如果您在開發環境中看到此警告，請確保您已在 Prisma Optimize 儀表板中啟動了錄製階段。

開啟於
複製為 Markdown
於 Claude 開啟
在 ChatGPT 中開啟
在 T3.chat 中開啟
在 GitHub 中編輯
© . This site is unofficial and not affiliated with Prisma Data, Inc.