Database Access in Serverless Environments: Connection Pooling and the Prisma Data Proxy

Serverless functions are stateless and short-lived, while database connections are stateful and expensive to open, and that mismatch exhausts connection limits the moment traffic spikes. The fix is an external connection pool between your functions and your database. The Prisma Data Proxy, announced in this 2021 post, was Prisma's first product to provide that pool; it has since been discontinued, and its job is done today by Prisma Postgres, which includes a built-in connection pool for serverless and edge apps. The problem this post explains is as real as ever; the product answer has changed.

Updated (July 2026): The Prisma Data Proxy has been discontinued. For connection pooling with Prisma ORM today, use Prisma Postgres: its connection pool works with serverless and edge functions out of the box, and it supports direct TCP connections for other tools. The sections below explain the underlying problem (still current) and preserve the original announcement for historical reference.

---

Serverless enables fast development

Serverless functions are a convenient tool that allow developers to quickly implement and deploy functionality that can then be invoked via HTTP requests.

A drastically reduced operational overhead, easy scaling thanks to the dynamic allocation of computational resources, and a consumption-based pricing model are more features of serverless functions that explain their popularity among developers.

Serverless is also integrated into frameworks like Next.js where an entire backend can be implemented via API routes. Deployed to serverless platforms like Vercel, every API route is mapped to a serverless function to handle incoming requests.

---

Stateful database connections don't map well to stateless serverless functions

However, as developers started to harness serverless functions for the use case of building their backends, they ran into an issue.

Accessing a database from a serverless function

Serverless functions are short-lived, ephemeral and rarely get reused. This means that as traffic spikes, the number of instances of a serverless function goes up as well.

This stateless nature of serverless functions doesn't map well to the statefulness of traditional databases that require a TCP connection between application and database server. This connection itself is kept open in memory and thus is part of the application state.

Let's quickly understand the exact issues that arise when talking to a database from serverless functions.

When a serverless function needs to access a database, it establishes a connection to it, submits a query and receives the response from the database. The response data is then delivered to the client that invoked the serverless function, the database connection is closed and the function is torn down again.

Serverless functions exhaust the connection limit

If the number of parallel function invocations is low, there are no issues. However, during traffic spikes, it can happen that a lot of parallel functions are spawned, each requiring its own database connection.

Traditional databases like PostgreSQL and MySQL typically have a database connection limit that can easily get exhausted in these situations. Once the database can't accept any new connections from newly spawned serverless functions, the requests made by the client applications start to fail.

Opening and closing a connection per request is slow

Another issue in this context is that the opening and closing of database connections is a fairly expensive operation to perform due to TLS termination and resource allocation for the connection in the database. This adds to the already existing problem of cold starts in serverless functions and slows down the execution of a request even more.

So besides the exhaustion of the database connection limit, performance can be impacted by the fact that database connections do not get reused.

---

Connection pooling to the rescue

The solution to the problems named above is called connection pooling. By creating a pool of database connections, it is ensured that database connections can be reused and pressure on the database is managed appropriately.

Traditional servers can maintain a connection pool

In traditional, server-based applications, managing a connection pool is not a problem because the server is able to maintain its state. In serverless functions, however, it is not possible to maintain a connection pool across incoming requests because of the stateless nature of the functions.

Serverless functions need an external connection pool

The only solution for serverless functions to get around the problem of database connection management is to introduce a proxy server in front of the database that manages a connection pool.

Existing tools like pgBouncer for PostgreSQL require notable overhead in managing an additional infrastructure component.

---

The original announcement: the Prisma Data Proxy (2021)

This section is preserved as history. The Data Proxy has been discontinued; see the alternatives below.

The Prisma Data Proxy was a proxy server for your database that managed a connection pool and ensured existing database connections were reused. This prevented incoming user requests from failing and improved the performance of your app.

The Data Proxy integrated with Prisma ORM and could be enabled via the Prisma Data Platform. At the time of this announcement it was in Early Access and not yet recommended for production use.

To learn how the Data Proxy worked, check out Daniel Norman's talk about it:

The Data Proxy also enabled use cases such as accessing a database from limited function environments like Cloudflare Workers.

What to use instead today

The problem this post describes has a simpler answer now than it did in 2021:

• Use Prisma Postgres if you want a managed Postgres database with connection pooling built in. It works with Prisma ORM out of the box, serves serverless and edge functions without connection exhaustion, and supports direct TCP connections for other tools.
• If you bring your own database, follow the current serverless deployment docs for up-to-date connection handling guidance, or run an external pooler like pgBouncer in front of your database.

Frequently asked questions

Looking ahead: Prisma Next is a TypeScript-native rewrite of Prisma ORM, built for AI coding agents and currently in early access. It becomes Prisma 8 at general availability; until then, Prisma 7 stays the production choice. To try it, run npm create prisma@next or read the early access docs.