Connection pooling

Prisma Postgres provides built-in connection pooling by default, enabled by Prisma Accelerate. By using Prisma Postgres, you get the benefits of connection pooling without 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.

In some cases, however, it may be beneficial to further configure connection pooling in order to optimize the performance of your application.

note

This document focuses on the connection pooling features of Prisma Postgres. For more information about the internal connection pool of Prisma ORM specifically, see our ORM connection pooling documentation.

Connection pooling in Prisma Postgres

Currently, Prisma Postgres allows a maximum of 10 concurrent database connections per Prisma Schema. This limit is typically sufficient due to Prisma Postgres's efficient unikernel-based architecture, which minimizes the need for large connection pools.

note

If you're using your own database with Prisma Accelerate, the connection limits differ:

• Starter plan: Maximum of 10 connections. This is often sufficient for most workloads, but if you're expecting high traffic or intensive compute operations, you may want to increase this limit.
• Pro plan: Supports up to 100 concurrent connections.
• Business plan: Supports up to 1000 concurrent connections.

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.

Configuring the 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.

Similar to the connection pool size, you may also configure the connection pool timeout via the database connection string. To adjust this value, you may add the pool_timeout parameter to the database connection string.

For example:

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

info

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:

Plan	Starter	Pro	Business
Query timeout	Up to 10 seconds	Up to 20 seconds	Up to 60 seconds

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:

Plan	Starter	Pro	Business
Interactive transaction limit	Up to 15 seconds	Up to 30 seconds	Up to 90 seconds

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:

Plan	Starter	Pro	Business
Query size	Up to 5MB	Up to 10MB	Up to 20MB

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 Starter plan.

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

Plan	Max Connection Limit
Starter	10
Pro	100
Business	1000
Enterprise	Contact Us