Connection pooling

Prisma Postgres provides built-in connection pooling without you having to configure anything. The efficient management of database connections allows the database to process more queries without exhausting the available database connections, making your application more scalable.

Connection pooling in Prisma Postgres

For Prisma Postgres, the connection limit depends on the plan you have signed up for.

You can compare plans on the Prisma pricing page.

Configuring the connection pool size

If you're not using Prisma Postgres, you can configure the connection pool size for Prisma ORM by specifying it in the connection string.

For Prisma Postgres, the connection limit is currently fixed at 10 and cannot be changed.

If you're using Prisma Accelerate with your own database, you can configure the connection pool size through the Connection limit setting in your project on the Accelerate setup page.

Connection pool timeout

The connection pool timeout is the maximum number of seconds that a query will block while waiting for a connection from Prisma Postgres's internal connection pool. This occurs if the number of concurrent requests exceeds the connection limit, resulting in queueing of additional requests until a free connection becomes available. An exception is thrown if a free connection does not become available within the pool timeout. The connection pool timeout can be disabled by setting the value to 0.

For example:

postgresql://user:password@localhost:5432/db?connection_limit=10&pool_timeout=20

The default value for pool_timeout is 10 seconds.

Configuring query limits

You can configure the minimum and maximum query response size, query duration, and transaction limits when using Prisma Accelerate from the Settings tab in your Prisma Postgres project environment.

Query timeout limit

Prisma Postgres has a default global timeout of 10s for each query, configurable using the slider labeled Query duration, based on your subscription plan:

See the error reference and our pricing page for more information.

:::warning

While you can increase the query timeout, it's recommended to inspect and optimize your database queries if they take longer than 10 seconds. This helps reduce stress on your underlying database, as long-running queries often indicate a need for optimization. Learn more in the error reference. :::

Interactive transactions query timeout limit

Prisma Postgres has a default global timeout of 15s for each interactive transaction, configurable using the slider labeled Transaction duration, based on your subscription plan:

See the error reference and our pricing page for more information.

When you set a higher interactive transaction timeout in the Prisma Console, you must also specify a matching timeout value in your interactive transaction query via timeout transaction option. Otherwise, transactions will still time out at the lower default (e.g., 5 seconds limit when no timeout value is specified). Here's an example of how to set a 30-second timeout in your code:

await prisma.$transaction(
  async (tx) => {
    // Your queries go here
  },
  {
    timeout: 30000, // 30s
  },
);

:::warning

While you can increase the interactive transaction timeout limit, it's recommended to inspect and optimize your database transactions if they take longer than 15 seconds. Long-running transactions can negatively impact performance and often signal the need for optimization. Learn more in the error reference and review the warning in the Interactive Transactions section in our documentation.

:::

Response size limit

Prisma Postgres has a default global response size limit of 5MB, configurable using the slider labeled Response size, based on your subscription plan:

See the error reference and our pricing page for more information.

:::warning

While you can increase the query response size, it’s recommended to limit data retrieval to what you actually need. This improves database performance, reduces stress on your database, and makes your frontend applications more responsive. Queries exceeding 5 MB in size often indicate a need for optimization. Learn more in the error reference.

:::

Autoscaling (Accelerate + Your own database only)

Autoscaling is currently available only when using Prisma Accelerate with your own database. It enables dynamic resource allocation based on your application's traffic. As usage nears the defined connection limit, Prisma will begin provisioning additional resources to handle the load. If traffic continues to grow, the system will scale out further. When traffic decreases, it scales back down—ensuring efficient use of resources.

How it works

Autoscaling is powered by a connection pooler that horizontally scales your environment by distributing total available connections across multiple Query Engine instances.

Here’s how this works in practice:

• Suppose your environment’s connection limit is set to 1000.
• Prisma Accelerate will scale up to multiple Query Engine instances (e.g., 100 instances).
• Each instance is allocated a share of the total—10 connections per instance, in this example.
• This is why each Query Engine instance reports a limit of 10, even though the full environment supports 1000 concurrent connections.

This distributed model allows your application to handle increased traffic by spinning up more Query Engine instances, while efficiently managing connection usage.

Enabling Autoscaling

Autoscaling is automatically enabled when your Accelerate connection limit is set above the default (10). This feature is not available on the Free or Starter plan.

Your environment's maximum connection limit is based on your Prisma Data Platform plan: