Prisma Postgres FAQ (/docs/postgres/faq)

For the complete Prisma documentation index, see llms.txt. A markdown version of any docs page is available by appending .md to its URL.

Common questions and answers about Prisma Postgres

Location: Postgres > Prisma Postgres FAQ

Common questions about how Prisma Postgres works, how queries are billed, and how it integrates with the Prisma ORM.

Yes, you can use Prisma Postgres with any database library or tool via a direct connection.

You can find examples of using Prisma Postgres with various ORMs below:

• Prisma ORM
• Drizzle
• Kysely
• TypeORM

If you previously signed up using GitHub and want to switch to email and password login, follow these steps:

1. Verify Your GitHub Email Address
   • Check the primary email address associated with your GitHub account (e.g., from your GitHub profile or notification settings).
2. Create a New Email/Password Account
   • Go to the email/password sign-up page.
   • Use the same email address linked to your GitHub account to create the new account.
   • Our system will automatically connect your new email/password account to your existing data.
3. Test Your Login
   • Log out and try logging in with your email and the password you just created.

If you encounter any issues, please contact our support team for help linking your accounts.

If you add the Prisma Client extension for Accelerate to an existing project that is currently open in VS Code, the editor might not immediately recognize the $extends method.

This might be an issue with the TypeScript server not yet recognizing the regenerated Prisma Client. To resolve this, you need to restart TypeScript.

1. In VS Code, open the Command Palette. You can do so when you press F1 or select View > Command Palette.
2. Enter typescript and select and run the TypeScript: Restart TS server command.

VS Code should now recognize the $extends method.

Prisma Postgres is currently available in the following regions:

We're continuously working to expand regional support. If you'd like to request a specific region, reach out to us via Discord.

Prisma Postgres bills based on operations and storage consumed. It does not charge for egress traffic. Visit the pricing page for details and our blog post explaining operations-based billing for a detailed explanation on what an operation is and how this pricing model works.

An operation is counted each time you interact with your database. A read or a write, simple or complex, counts as one operation.

An operation can be:

• a Prisma ORM query (when using Prisma ORM)
• a SQL query (when using a direct connection)

No, cost for Prisma Postgres is based solely on the number of operations, not the amount of compute required to execute them.

Whether a query takes 10ms or 10sec to execute, its pricing impact remains the same.

The fundamental principle of operations-based pricing remains the same for Prisma ORM and direct connections. However, depending on whether you use Prisma ORM or direct SQL to interact with your database, an operation is something different:

• when using Prisma ORM: a query sent with Prisma Client (e.g. prisma.user.findMany())
• when using another tool: a SQL query sent via the direct connection (e.g. SELECT * from "User")

Note that a single Prisma ORM query may translate into multiple SQL queries which may make using Prisma ORM more economical than direct SQL.

Yes, read and write queries are counted equally as operations and are billed the same way.

Yes, a query like SELECT 1 counts as an operation and will be billed accordingly (even if no actual data is accessed in the query).

You can estimate your operation usage in Prisma ORM by integrating an application performance monitoring tool like Prometheus.

Prisma Postgres bills by operation. The more you can perform using a single operation, the lower your bill. Some tips to reduce the number of operations:

• Batch your writes with createMany, updateMany, or deleteMany instead of looping over single-row calls.

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

• Use nested-relation helpers such as connectOrCreate or set to create or link related records in a single operation.

  // 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" },
        },
      },
    },
  });

• Prefer regular (array) transactions over interactive transactions when the individual queries don't depend on each other.

  // 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 } }),
  ]);

If a later query needs the result of an earlier one (for example, you need the user ID you just created), stick with an interactive transaction for correctness. Otherwise, batching and array transactions let you collapse multiple queries into a single billed operation, keeping both your operation count, and your cost down.

We will demonstrate three example workloads and estimate bills for small, medium, and large workloads. Each combine a realistic number of monthly active users (MAUs), a typical level of daily activity per user, and a rounded storage footprint.

We will use the following equations to estimate the monthly bill:

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

[!NOTE] You can use your own MAU count, activity level, and storage used to project costs on any plan using the equations above.

We will associate each workload with a paid plan and its corresponding pricing details, for example, the Starter plan for the small workload, the Pro plan for the medium workload, and the Business plan for the large workload. Then we will apply the equations to the example workloads to generate a rough estimate of a monthly bill. For example:

[!NOTE] Pricing details

Here are the details for each pricing plan:

• Starter plan - $8 per million operations
  • Base plan fee - $10 per month
  • Included operations - 1,000,000
  • Storage - 10 GB free then $2 per additional GB
• Pro plan - $2 per million operations
  • Base plan fee - $49.00 per month
  • Included operations - 10,000,000
  • Storage - 50 GB free then $1.5 per additional GB
• Business plan - $1 per million operations
  • Base plan fee - $129.00 per month
  • Included operations - 50,000,000
  • Storage - 100 GB free then $1 per additional GB

We also have a Free plan, but we are leaving it out in the following calculations because it's intended for evaluation only and is not meant for production workloads. You can also learn more about the pricing details for each plan on the pricing page.

Example of a small workload on the Starter plan:

A hobby or early-stage side-project with ~500 MAUs. Each user performs ~10 actions per day, and the entire database uses ~0.5 GB of storage. Based on the assumptions, you would calculate the monthly bill using the following equations:

• total_ops = 500 x 10 x 30 = 150000
• billable_ops = 0 (150,000 operations is below the 1 million free operations)
• ops_cost = $0
• storage_cost = $0 (0.5 GB is below the 10 GB storage already included)
• base_plan_fee = $10

total_monthly_cost = $10.00 per month

Example of a medium workload on the Pro plan:

A growing SaaS product serving ~5000 MAUs. Power users average ~40 actions per day, and the app stores ~6 GB of data. Based on the assumptions, you would calculate the monthly bill using the following equations:

• total_ops = 5000 x 40 x 30 = 6000000
• billable_ops = 0 (6 million operations is below the 10 million free operations)
• ops_cost = $0
• storage_cost = $0 (6 GB is below the 50 GB storage already included)
• base_plan_fee = $49.00

total_monthly_cost = $49.00 per month

Example of a large workload on the Business plan:

A production-grade, consumer-facing application handling ~50000 MAUs. Heavy usage with ~60 actions per user per day drives significant traffic, and the dataset reaches ~40 GB. Based on the assumptions, you would calculate the monthly bill using the following equations:

• 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 is below the 100 GB storage already included)
• base_plan_fee = $129.00

total_monthly_cost = $40.00 + $129.00 = $169.00 per month

If you installed Prisma Postgres through the Vercel Marketplace integration, the same Prisma Postgres pricing plans apply and your usage is billed through your Vercel account. To upgrade your plan via Vercel, follow these steps:

• Open your Vercel Dashboard.
• Go to the Integrations tab in your Vercel Team.
• Click Manage on the Prisma Integration.
• Navigate to the Settings tab.
• Under Current Installation Plan Level, click Change Plan.
• Select the plan you want to upgrade to.

Prisma Postgres includes connection pooling but has no query cache of its own, and query caching is not on our immediate roadmap. cacheStrategy works with a Prisma Postgres database only through a hosted Accelerate connection.

If your application passes cacheStrategy through a hosted Accelerate connection, that connection will be retired on December 1, 2026. Connect to Prisma Postgres without Accelerate shows how to remove the caching APIs and replace the connection. After the switch, cached queries become ordinary database queries. A query served from the cache already counted as one operation, so removing caching does not change how operations are counted. Database load and response latency can change, so test the affected paths under representative traffic.

Yes, you can increase your Prisma Postgres limits based on your subscription plan. Here are the configurable limits:

Check the pricing page for more details on the available plans and their corresponding limits.

[!WARNING] While you can increase these limits based on your subscription plan, it's still recommended to optimize your database operations. Learn more in our troubleshooting guide.

Query Insights is built into Prisma Postgres and helps you identify slow queries, understand their cost, and decide what to fix.

By default, Query Insights shows raw SQL. To also see the Prisma ORM operation that generated each query (model name, action, and query shape), install the @prisma/sqlcommenter-query-insights package:

npm install @prisma/sqlcommenter-query-insights

Then pass it to the comments option in your PrismaClient constructor:

import { prismaQueryInsights } from "@prisma/sqlcommenter-query-insights";
import { PrismaClient } from "@prisma/client";

const prisma = new PrismaClient({
  adapter: myAdapter,
  comments: [prismaQueryInsights()],
});

This annotates every query with a SQL comment containing the model, action, and parameterized query shape. Query Insights uses these annotations to map SQL back to the Prisma call that generated it.

Copy this prompt into your AI coding assistant:

Install and configure @prisma/sqlcommenter-query-insights in my project so I can
see Prisma ORM queries in Query Insights. Docs: https://www.prisma.io/docs/query-insights

No. Query Insights is read-only: it observes query behavior but does not rewrite queries or modify your Prisma schema.

Query Insights is designed primarily for development and debugging. Running it in production is possible but not recommended, as the SQL comment annotations add a small overhead to every query.

• Best Postgres for AI apps: Why Prisma Postgres works well for AI and LLM workloads: built-in pooling, edge connectivity, pgvector, and MCP support.
• create-db: Learn how to provision temporary Prisma Postgres databases with create-db
• Database: Overview of Prisma Postgres database operations, connections, pooling, backups, and query analysis.
• Error reference: Error reference documentation for Prisma Postgres
• Import from existing database: Choose the right path to import data from PostgreSQL or MySQL into Prisma Postgres.