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

## General 

### Can I use Prisma Postgres without Prisma ORM?  

Yes, you can use Prisma Postgres with any database library or tool via a [direct connection](/postgres/database/direct-connections).

### How do I switch from GitHub login to email and password login?

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.


### VS Code does not recognize the `$extends` method

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.

## What regions is Prisma Postgres available in?

Prisma Postgres is currently available in the following regions:

| Region Code      | Location       |
| ---------------- | -------------- |
| `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      |

We're continuously working to expand regional support. If you'd like to request a specific region, reach out to us via [Discord](https://pris.ly/discord).

## Pricing

Prisma Postgres bills based on _operations_ and _storage_ consumed. Visit the [pricing page](https://www.prisma.io/pricing) for details and our [blog post explaining operations-based billing](https://www.prisma.io/blog/operations-based-billing) for a detailed explanation on what an operation is and how this pricing model works.

### What is an operation?

An operation is counted each time you interact with your database. Read, write, simple or complex. It all simply counts as one. 

An operation can be:
- a Prisma ORM query (when using Prisma ORM)
- a SQL query (when using a [direct TCP connection](/postgres/database/direct-connections))

### Does query execution time affect pricing in Prisma Postgres?

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.

### How does pricing differ between using Prisma ORM and direct TCP connections?

The fundamental principle of operations-based pricing remains the same for Prisma ORM and [direct TCP connection](/postgres/database/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.

### Do read and write queries cost the same?

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

### Does a `SELECT 1` query count as a billable operation?

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).

### How can I estimate the number of operations in Prisma ORM?

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

### What strategies can I use to optimize cost per operation?

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**](/orm/prisma-client/queries/transactions#batchbulk-operations) with `createMany`, `updateMany`, or `deleteMany` instead of looping over single-row calls.

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

- **Use nested-relation helpers** such as [`connectOrCreate`](/orm/reference/prisma-client-reference#connectorcreate) or [`set`](/orm/reference/prisma-client-reference#set) to create or link related records in a single operation.

  ```ts
  // 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](/orm/prisma-client/queries/transactions#transaction-api) over [interactive transactions](/orm/prisma-client/queries/transactions#interactive-transactions)** when the individual queries don't depend on each other.

  ```ts
  // 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.

### Is there a sample workload to estimate my expected charges?

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](https://www.prisma.io/pricing?utm_source=docs).

:::

**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

### Are cached operations billed the same?

Every request, whether it hits the database or is served from cache, counts as an operation. Prisma Postgres use a flat per-operation price and never charge for egress traffic, so a cached response doesn't incur any extra or reduced fee. This unified rate keeps the billing model predictable and avoids per-request complexity.

### How do I upgrade my plan if I am using Prisma Postgres via Vercel?

To upgrade your plan via Vercel, follow these steps:

- Open your [Vercel](https://vercel.com/) 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.

## Caching 

Prisma Postgres includes built-in connection pooling and global caching. These features improve performance by optimizing how your queries are routed and cached.


### How does Prisma Postgres's cache layer know what region to fetch the cache from?

Under the hood, Prisma Postgres's cache layer uses Cloudflare, which uses [Anycast](https://www.cloudflare.com/learning/cdn/glossary/anycast-network/) for network addressing and routing. An incoming request will be routed to the nearest data center or "node" in their network that has the capacity to process the request efficiently. To learn more about how this works, we recommend looking into [Anycast](https://www.cloudflare.com/learning/cdn/glossary/anycast-network/).

### How can I invalidate a cache for Prisma Postgres?

You can invalidate the cache on-demand via the [`$accelerate.invalidate` API](/accelerate/api-reference#accelerateinvalidate) if you're on a [paid plan](https://www.prisma.io/pricing#accelerate), or you can invalidate your entire cache, on a project level, a maximum of five times a day. This limit is set based on [your plan](https://www.prisma.io/pricing). You can manage this via the Accelerate configuration page.

### What is Prisma Postgres's caching layer's consistency model?

The caching layer in Prisma Postgres does not have a consistency model. It is not a distributed system where nodes need to reach a consensus (because data is only stored in the cache node(s) closest to the user). However, the data cached in Prisma Postgres's cache nodes doesn't propagate to other nodes, so the cache layer by design doesn't need a consistency model.

Prisma Postgres implements a [read-through caching strategy](https://www.prisma.io/dataguide/managing-databases/introduction-database-caching#read-through) particularly suitable for read-heavy workloads.

The freshness of the data served by the cache depends on the cache strategy defined in your query. Refer to [this section](/postgres/database/caching#selecting-a-cache-strategy) for more information on selecting the right cache strategy for your query.

### How is Prisma Postgres's caching layer different from other caching tools, such as Redis?

The caching layer of Prisma Postgres:

- Is a _specialized_ cache that allows you to optimize data access in code at the query level with a cache strategy. On the other hand, tools such as Redis and Memcached are _general-purpose_ caches designed to be adaptable and flexible.
- Is a managed service that reduces the time, risk, and engineering effort of building and maintaining a cache service.
- Is globally distributed, by default, reducing the latency of your queries. Other cache tools would require additional configuration to make them available globally.

### When should I not use Prisma Postgres's caching features?

The caching layer of Prisma Postgres is a global data cache and connection pool that allows you to optimize data access in code at the query level. While caching with Prisma Postgres can greatly boost the performance of your app, it may not always the best choice for your use case.

This global cache feature may not be a good fit for your app if:

- Your app is exclusively used within a specific region and both your application server and database are situated in that same region on the same network. For example, database queries will likely be much faster if your application server and database are in the same region and network. However, If your application server is in different regions or networks from your database, the cache nodes will speed up your queries because the data will be cached in the closest data center to your application.

- Your application data _always_ needs to be up-to-date on retrieval, making it difficult to establish a reasonable cache strategy.

### What is the maximum allowed value for the `ttl` parameter when configuring `cacheStrategy`?

The [Time-to-live](/postgres/database/caching#time-to-live-ttl) (`ttl`) parameter can be set for up to a _year_. However, it's important to note that items within the cache may be evicted if they are not frequently accessed.

Based on our experimentation, we’ve seen cache items persist for around 18 hours. While items may remain in the cache for an extended period if they are actively accessed, there is no guarantee.

:::note

Even frequently accessed items may occasionally be evicted from the cache. It's unlikely for an item to survive for up to or longer than a month, regardless of its activity level.

:::

### Why do I sometimes see unexpected cache behavior?

Prisma Postgres's cache layer performs best when it observes a higher load from a project. Many cache operations, such as committing data to cache and refreshing stale data, happen asynchronously. When benchmarking the cache layer, we recommend doing so with loops or a load testing approach. This will mimic higher load scenarios better and reduce outliers from low frequency operations.

Prisma operations are sent to Prisma Postgres over HTTP. As a result, the first request to Prisma Postgres must establish an HTTP handshake and may have additional latency as a result. We're exploring ways to reduce this initial request latency in the future.

### What regions are Prisma Postgres's cache nodes available in?

Prisma Postgres's cache layer runs on Cloudflare's network and cache hits are served from Cloudflare's 300+ locations. You can find the regions where Prisma Postgres's cache nodes are available here: [https://www.cloudflare.com/network/](https://www.cloudflare.com/network/).

### How long does it take to invalidate a cache query result?

As the cache needs to be cleared globally, it is difficult to provide a specific time frame. However, the cached data is eventually consistent and typically propagates to all PoPs within a few seconds. In very rare cases, it may take longer.

Here is a [demo app](https://pris.ly/test-cache-invalidation) to test the time it takes to invalidate a cache query result.

### What is the difference between **Invalidate** and **Revalidate**?

**Invalidate**: The cache entry is deleted, and new data will be fetched on the next request, causing a cache miss. This removes stale data but may lead to slower responses until the cache is repopulated.

**Revalidate**: The cache entry is updated proactively, ensuring the next request uses fresh data from the cache. This keeps the cache valid and maintains faster response times by avoiding cache misses.

### What is on-demand cache invalidation?

[On-demand cache invalidation](/postgres/database/caching#on-demand-cache-invalidation) lets applications instantly update specific cached data when it changes, instead of waiting for regular cache refresh cycles. This keeps information accurate and up-to-date for users.

### When should I use the cache invalidate API?

The [cache invalidate API](/postgres/database/caching#on-demand-cache-invalidation) is essential when data consistency cannot wait for the cache’s standard expiration or revalidation. Key use cases include:

- **Content updates**: When critical changes occur, such as edits to a published article, product updates, or profile modifications, that need to be visible immediately.
- **Inventory management**: In real-time applications, like inventory or booking systems, where stock levels, availability, or reservation statuses must reflect the latest information.
- **High-priority data**: For time-sensitive data, like breaking news or urgent notifications, where it’s essential for users to see the most current information right away.

Using on-demand cache invalidation in these scenarios helps keep only the necessary data refreshed, preserving system performance while ensuring accurate, up-to-date information for users.


## Connection pooling

#### Can I increase the query duration and response size limits for my Prisma Postgres instance?

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

| Limit                                | Free             | Starter           | Pro Plan          | Business Plan     |
|--------------------------------------|------------------|-------------------|-------------------|-------------------|
| **Query timeout**                    | Up to 10 seconds  | Up to 10 seconds  | Up to 20 seconds  | Up to 60 seconds  |
| **Interactive transactions timeout** | Up to 15 seconds  | Up to 15 seconds  | Up to 30 seconds  | Up to 90 seconds  |
| **Response size**                    | Up to 5 MB       | Up to 5 MB        | Up to 10 MB       | Up to 20 MB       |

Check the [pricing page](https://www.prisma.io/pricing) 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.](/postgres/database/api-reference/error-reference)
:::


## Query optimization

Prisma Postgres allows query optimization via [Prisma Optimize](/optimize) and provides performance recommendations to help improve your database queries during development. You can enable it with Prisma Postgres or [also use it with your own database](/optimize/getting-started), but setup and integration steps differ.

### Can you automatically implement optimizations?

Prisma Postgres's query optimization feature offers insights and recommendations on how to improve your database queries. It does not alter any existing queries or your Prisma schema.

### How long is a recording session retained?

There are no limits on the storage retention period. A query performance recording session will be stored until you explicitly delete it.

### Do recommendation limits reset monthly?

Yes, the recommendation usage resets at the beginning of each calendar month. For example, if you use `5` recommendations by the end of the month, your usage will reset to `0` at the start of the next month.

### Can I get charged for exceeding the recommendation limit on the starter plan?

Yes, if you’re on the starter plan, exceeding `5` recommendations in a billing cycle will result in a `$5` charge at the end of that cycle. For more information, visit [our pricing page](https://www.prisma.io/pricing#optimize).

### How are viewed Prisma AI recommendations tracked for billing? Are they counted based on generated or viewed recommendations?

They are counted based on viewed recommendations. Once you click on a recommendation from the recommendations table and view the recommendation's detail page, it counts as being seen.

### Can I enable query optimizations for Prisma Postgres in production?

No, query optimizations for Prisma Postgres is not meant to be enabled for production use. It is specifically designed for local development, providing valuable insights and optimizations during that phase. While it's technically possible to run it in a production environment, doing so could result in performance problems or unexpected behaviors, as this is not built to handle the complexity and scale of production workloads. For the best experience, we recommend testing query optimization solely in your development environment.

You can use the `enable` property in the client extension to run it [only in development environment](https://www.npmjs.com/package/@prisma/extension-optimize). By default, the `enable` property is set to `true`.

```ts file=script.ts copy showLineNumbers
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',
  })
);
```

### Why do I see "[optimize] HTTP 409 Conflict: There is no active recording to write queries to" warning?

This warning may occur when Prisma Optimize receives queries but no recording session is active. Typically, this can happen if Prisma Optimize is unintentionally enabled in your production environment. Prisma Optimize is specifically designed for use in local development environments and should not be enabled in production. To avoid this warning, ensure that Prisma Optimize is configured to run only during development.

If you are seeing this warning in your development environment, ensure that you have started a recording session in the Prisma Optimize Dashboard.

---

# Troubleshooting Prisma Postgres issues