メインコンテンツへスキップ

Prisma Postgres FAQ

Prisma Postgresの動作方法、クエリの課金方法、およびPrisma ORMとの連携方法に関するよくある質問です。

一般​

Prisma ORMなしでPrisma Postgresを使用できますか？​

はい、ダイレクト接続を介して、任意のデータベースライブラリやツールでPrisma Postgresを使用できます。

GitHubログインからメールとパスワードでのログインに切り替えるにはどうすればよいですか？​

以前GitHubを使用して登録し、メールとパスワードでのログインに切り替えたい場合は、以下の手順に従ってください。

  1. GitHubのメールアドレスを確認する
    • GitHubアカウントに紐付けられているプライマリメールアドレス（例：GitHubプロフィールまたは通知設定から）を確認してください。
  2. 新しいメール/パスワードアカウントを作成する
    • メール/パスワードの登録ページに移動します。
    • GitHubアカウントにリンクされている同じメールアドレスを使用して、新しいアカウントを作成します。
    • 当社のシステムが、新しいメール/パスワードアカウントを既存のデータに自動的に接続します。
  3. ログインをテストする
    • ログアウトし、作成したばかりのメールとパスワードでログインしてみてください。
注

問題が発生した場合は、アカウントの連携について当社のサポートチームにお問い合わせください。

VS Codeが$extendsメソッドを認識しない​

VS Codeで現在開いている既存のプロジェクトに、Accelerate用のPrisma Client拡張機能を追加した場合、エディターが$extendsメソッドをすぐに認識しないことがあります。

これは、TypeScriptサーバーが再生成されたPrisma Clientをまだ認識していないことが原因である可能性があります。これを解決するには、TypeScriptを再起動する必要があります。

  1. VS Codeで、コマンドパレットを開きます。F1キーを押すか、表示 > コマンドパレットを選択して開くことができます。
  2. typescriptと入力し、TypeScript: TSサーバーの再起動コマンドを選択して実行します。

これでVS Codeは$extendsメソッドを認識するはずです。

料金​

Prisma Postgresは、消費された操作とストレージに基づいて課金されます。詳細については、料金ページを、操作とは何か、この料金モデルがどのように機能するかについての詳細な説明については、操作ベースの課金を説明するブログ投稿をご覧ください。

操作とは何ですか？​

操作は、データベースとやり取りするたびにカウントされます。読み取り、書き込み、シンプル、複雑にかかわらず、すべて1回としてカウントされます。

操作には以下が含まれます

  • 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での操作数を推定するにはどうすればよいですか？​

Prisma ORMのmetricsプレビュー機能をPrometheusのようなアプリケーションパフォーマンス監視ツールと連携させることで、Prisma ORMでの操作使用量を推定できます。metricsプレビュー機能を有効にすると、prisma_client_queries_totalメトリクスで操作数を確認できます。

Prisma Postgresは、課金を計算するためにデータベースに送信されるすべてのクライアント操作を追跡するprisma_client_queries_totalカウンターを使用します。Prometheusの設定とアプリケーションの監視に関する詳細なステップバイステップのチュートリアルは、完全なガイドをご覧ください。

操作あたりのコストを最適化するためにどのような戦略を使用できますか？​

Prisma Postgresは操作ごとに課金されます。1回の操作でより多くの処理を実行できるほど、請求額は低くなります。操作数を減らすためのヒントをいくつか紹介します。

  • 単一行の呼び出しをループするのではなく、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' },
          },
        },
      },
    })

  • 個々のクエリが互いに依存しない場合は、インタラクティブトランザクションよりも通常の（配列）トランザクションを推奨します。

    // 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が必要な場合）は、正確性を確保するためにインタラクティブトランザクションを使用してください。そうでない場合、バッチ処理と配列トランザクションにより、複数のクエリを単一の課金操作に集約できるため、操作数とコストの両方を抑えることができます。

予想される料金を見積もるためのサンプルワークロードはありますか？​

ここでは、小規模、中規模、大規模のワークロードに対する3つの例示的なワークロードと推定請求額を示します。それぞれが、現実的な月間アクティブユーザー数（MAU）、ユーザーあたりの典型的な日次アクティビティレベル、および丸められたストレージ使用量を組み合わせています。

月額料金を見積もるには、以下の計算式を使用します。

total_ops            = MAUs x actions_per_user_per_day x 30      
billable_ops         = total_ops - 100_000
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 Annualプランを適用します。次に、これらの計算式を例示的なワークロードに適用して、月額料金のおおよその見積もりを生成します。例:

料金詳細

各料金プランの詳細は以下のとおりです。

  • Starterプラン - 100万操作あたり$18
    • 基本プラン料金 - 月額$0
    • ストレージ - 1GB無料、その後1GBあたり$2
  • Proプラン - 100万操作あたり$8
    • 基本プラン料金 - 月額$49.00
    • ストレージ - 5GB無料、その後1GBあたり$1.5
  • Business Annualプラン - 月間5,000万～1億操作の利用枠で100万操作あたり$4
    • 基本プラン料金 - 月額$129.00
    • ストレージ - 10GB無料、その後1GBあたり$1

各プランの料金詳細については、料金ページでもご確認いただけます。

Starterプランでの小規模ワークロードの例:

約500 MAUの趣味または初期段階のサイドプロジェクト。各ユーザーが1日あたり約10アクションを実行し、データベース全体が約0.5GBのストレージを使用します。これらの仮定に基づき、以下の計算式を使用して月額料金を算出します。

  • total_ops = 500 x 10 x 30 = 150000
  • billable_ops = 50000
  • ops_cost = (50000 ÷ 1000000) x $18 = $0.90
  • storage_cost = $0 (0.5 GBは1 GBの無料枠以下)
  • base_plan_fee = $0

total_monthly_cost = 月額$0.90

Proプランでの中規模ワークロードの例:

約5000 MAUをサービスする成長中のSaaS製品。パワーユーザーは1日あたり平均約40アクションを実行し、アプリは約6 GBのデータを保存します。これらの仮定に基づき、以下の計算式を使用して月額料金を算出します。

  • total_ops = 5000 x 40 x 30 = 6000000
  • billable_ops = 5900000
  • ops_cost = (5900000 ÷ 1000000) = 5.9 x $8 = $47.20
  • storage_cost = (6 GB - 5 GB) x $1.50 = $1.50
  • base_plan_fee = $49.00

total_monthly_cost = $47.20 + $1.50 + $49.00 = 月額$97.70

Business Annualプランでの大規模ワークロードの例:

約50000 MAUを扱う、プロダクション品質の消費者向けアプリケーション。1日あたりユーザーごとに約60アクションというヘビーな利用により、膨大なトラフィックが発生し、データセットは最大約40 GBに達します。これらの仮定に基づき、以下の計算式を使用して月額料金を算出します。

  • total_ops = 50000 x 60 x 30 = 90000000
  • billable_ops = 89900000
  • ops_cost = (89900000 ÷ 1000000) = 89.9 x $4 = $359.6
  • storage_cost = (40 GB - 10 GB) x $1 = $30.00
  • base_plan_fee = $129.00

total_monthly_cost = $359.6 + $30.00 + $129.00 = 月額$518.60

キャッシュされた操作も同じように課金されますか？​

データベースにアクセスする場合でも、キャッシュから提供される場合でも、すべてのリクエストは操作としてカウントされます。Prisma Postgresは操作ごとの均一料金を使用し、送信トラフィックの料金を請求しないため、キャッシュされた応答に追加料金や割引料金は発生しません。この統一料金により、課金モデルの予測可能性が保たれ、リクエストごとの複雑さが解消されます。

キャッシュ​

Prisma Postgresには、組み込みのコネクションプールとグローバルキャッシュが含まれています。これらの機能は、クエリのルーティングとキャッシュ方法を最適化することでパフォーマンスを向上させます。

Prisma Postgresのキャッシュ層は、どのリージョンからキャッシュを取得するかをどのようにして知るのですか？​

内部的には、Prisma Postgresのキャッシュ層はCloudflareを使用しており、Cloudflareはネットワークアドレス指定とルーティングにAnycastを使用しています。受信したリクエストは、そのネットワーク内でリクエストを効率的に処理できる最も近いデータセンターまたは「ノード」にルーティングされます。この仕組みの詳細については、Anycastについて調べることをお勧めします。

Prisma Postgresのキャッシュを無効にするにはどうすればよいですか？​

有償プランをご利用の場合、$accelerate.invalidate APIを介してオンデマンドでキャッシュを無効にできます。または、プロジェクトレベルで、1日最大5回までキャッシュ全体を無効にできます。この制限は、お客様のプランに基づいて設定されます。これはAccelerate設定ページで管理できます。

Prisma Postgresのキャッシュ層の整合性モデルは何ですか？​

Prisma Postgresのキャッシュ層には整合性モデルはありません。これは、ノードが合意に達する必要がある分散システムではありません（データはユーザーに最も近いキャッシュノードにのみ保存されるため）。ただし、Prisma Postgresのキャッシュノードにキャッシュされたデータは他のノードに伝播しないため、キャッシュ層は設計上、整合性モデルを必要としません。

Prisma Postgresは、読み取り負荷の高いワークロードに特に適したリードスルーキャッシュ戦略を実装しています。

キャッシュによって提供されるデータの鮮度は、クエリで定義されたキャッシュ戦略によって異なります。クエリに適したキャッシュ戦略の選択に関する詳細については、このセクションを参照してください。

Prisma Postgresのキャッシュ層は、Redisなどの他のキャッシュツールとどのように異なりますか？​

Prisma Postgresのキャッシュ層

  • キャッシュ戦略を用いてクエリレベルでコード内のデータアクセスを最適化できる専門的なキャッシュです。一方、RedisやMemcachedなどのツールは、適応性と柔軟性を持つように設計された汎用キャッシュです。
  • キャッシュサービスの構築と保守にかかる時間、リスク、エンジニアリング作業を削減するマネージドサービスです。
  • デフォルトでグローバルに分散されており、クエリのレイテンシーを削減します。他のキャッシュツールは、グローバルに利用できるようにするために追加の設定が必要です。

Prisma Postgresのキャッシュ機能を使用すべきでないのはいつですか？​

Prisma Postgresのキャッシュ層は、コード内のクエリレベルでデータアクセスを最適化できるグローバルデータキャッシュおよびコネクションプールです。Prisma Postgresでのキャッシングはアプリケーションのパフォーマンスを大幅に向上させることができますが、常にユースケースに最適な選択肢であるとは限りません。

以下の場合、このグローバルキャッシュ機能はあなたのアプリケーションに適さないかもしれません。

  • あなたのアプリケーションが特定のリージョン内でのみ使用され、アプリケーションサーバーとデータベースの両方が同じネットワーク上の同じリージョンに配置されている場合。例えば、アプリケーションサーバーとデータベースが同じリージョンとネットワークにある場合、データベースクエリははるかに高速になる可能性があります。ただし、アプリケーションサーバーがデータベースとは異なるリージョンまたはネットワークにある場合、データはアプリケーションに最も近いデータセンターにキャッシュされるため、キャッシュノードはクエリを高速化します。

  • アプリケーションデータが取得時に常に最新である必要がある場合、適切なキャッシュ戦略を確立することが困難になります。

cacheStrategyを設定する際のttlパラメーターの最大許容値は何ですか？​

The Time-to-live (ttl) パラメーターは、最大1年まで設定できます。ただし、キャッシュ内の項目は、頻繁にアクセスされない場合、削除される可能性があることに注意することが重要です。

私たちの実験によると、キャッシュ項目は約18時間持続することが確認されています。頻繁にアクセスされる項目は長期間キャッシュに残る可能性がありますが、保証はありません。

:::[注]

頻繁にアクセスされる項目でも、キャッシュから時々削除されることがあります。アクティビティレベルにかかわらず、項目が1ヶ月以上キャッシュに存続することは稀です。

:::

予期せぬキャッシュの動作が見られるのはなぜですか？​

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（無効化）: キャッシュエントリが削除され、次のリクエストで新しいデータがフェッチされるため、キャッシュミスが発生します。これにより古いデータは削除されますが、キャッシュが再投入されるまで応答が遅くなる可能性があります。

Revalidate（再検証）: キャッシュエントリは事前に更新され、次のリクエストでキャッシュから新しいデータが使用されることを保証します。これにより、キャッシュは有効に保たれ、キャッシュミスを回避することで応答時間が高速に維持されます。

オンデマンドキャッシュ無効化とは何ですか？​

オンデマンドキャッシュ無効化により、アプリケーションは定期的なキャッシュ更新サイクルを待つことなく、特定のキャッシュされたデータが変更されたときに即座に更新できます。これにより、ユーザーにとって情報が正確かつ最新に保たれます。

キャッシュ無効化APIはいつ使用すべきですか？​

データの一貫性がキャッシュの標準的な有効期限切れや再検証を待てない場合、キャッシュ無効化APIが不可欠です。主なユースケースは次のとおりです。

  • コンテンツの更新: 公開された記事の編集、製品の更新、プロフィールの変更など、すぐに反映させる必要がある重要な変更が発生した場合。
  • 在庫管理: 在庫レベル、可用性、予約状況が最新の情報を反映する必要がある、在庫管理や予約システムなどのリアルタイムアプリケーションの場合。
  • 高優先度データ: 速報ニュースや緊急通知など、ユーザーが最新情報をすぐに確認することが不可欠な、時間的制約のあるデータの場合。

これらのシナリオでオンデマンドキャッシュ無効化を使用することで、必要なデータのみを最新の状態に保ち、システムパフォーマンスを維持しながら、ユーザーに正確で最新の情報を提供できます。

コネクションプール​

Prisma Postgresインスタンスのクエリ時間と応答サイズの制限を増やすことはできますか？​

はい、サブスクリプションプランに基づいてPrisma Postgresの制限を増やすことができます。設定可能な制限は以下のとおりです。

制限StarterProプランBusinessプラン
クエリタイムアウト最大10秒最大20秒最大60秒
インタラクティブトランザクションのタイムアウト最大15秒最大30秒最大90秒
応答サイズ最大5MB最大10MB最大20MB

利用可能なプランと対応する制限の詳細については、料金ページをご確認ください。

警告

これらの制限はサブスクリプションプランに基づいて増やすことができますが、データベース操作を最適化することは引き続き推奨されます。トラブルシューティングガイドで詳細をご確認ください。

クエリ最適化​

Prisma Postgresでは、Prisma Optimizeを介してクエリ最適化が可能であり、開発中にデータベースクエリを改善するためのパフォーマンス推奨事項を提供します。Prisma Postgresで有効にするか、独自のデータベースでも使用できますが、セットアップと統合の手順が異なります。

最適化を自動的に実装できますか？​

Prisma Postgresのクエリ最適化機能は、データベースクエリを改善する方法に関する洞察と推奨事項を提供します。既存のクエリやPrismaスキーマを変更することはありません。

記録セッションはどのくらいの期間保持されますか？​

ストレージ保持期間に制限はありません。クエリパフォーマンス記録セッションは、明示的に削除するまで保存されます。

推奨事項の制限は毎月リセットされますか？​

はい、推奨事項の利用状況は毎月の初めにリセットされます。例えば、月末までに5つの推奨事項を使用したとしても、翌月の初めには使用量が0にリセットされます。

Starterプランで推奨事項の制限を超過した場合、料金が発生しますか？​

はい、Starterプランをご利用の場合、請求サイクル中に5つを超える推奨事項を利用すると、そのサイクルの終わりに$5の料金が発生します。詳細については、料金ページをご覧ください。

閲覧されたPrisma AIの推奨事項はどのように課金のために追跡されますか？生成された推奨事項と閲覧された推奨事項のどちらに基づいてカウントされますか？​

閲覧された推奨事項に基づいてカウントされます。推奨事項テーブルから推奨事項をクリックし、その詳細ページを表示すると、それが閲覧されたとカウントされます。

本番環境でPrisma Postgresのクエリ最適化を有効にできますか？​

いいえ、Prisma Postgresのクエリ最適化は、本番環境での使用を目的としていません。これはローカル開発用に特別に設計されており、そのフェーズで貴重な洞察と最適化を提供します。技術的には本番環境で実行することも可能ですが、本番ワークロードの複雑さと規模を処理するように構築されていないため、パフォーマンスの問題や予期せぬ動作につながる可能性があります。最適なエクスペリエンスを得るには、開発環境のみでクエリ最適化をテストすることをお勧めします。

クライアント拡張機能の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: クエリを書き込むアクティブな記録がありません」という警告が表示されるのはなぜですか？​

この警告は、Prisma Optimizeがクエリを受信しても記録セッションがアクティブでない場合に発生することがあります。通常、これはPrisma Optimizeが本番環境で意図せず有効になっている場合に発生します。Prisma Optimizeはローカル開発環境での使用に特化して設計されており、本番環境で有効にすべきではありません。この警告を回避するには、Prisma Optimizeが開発中のみ実行されるように設定されていることを確認してください。

開発環境でこの警告が表示される場合は、Prisma Optimizeダッシュボードで記録セッションを開始していることを確認してください。

© . All rights reserved.