---
title: Connecting to Neon from Vercel
subtitle: Learn how Vercel Fluid compute optimizes database connections and why standard
  TCP is the recommended method.
summary: >-
  Covers the setup of standard Postgres TCP connections and connection pooling
  for optimizing database interactions between Vercel's Fluid compute model and
  Neon, highlighting performance improvements over traditional methods.
enableTableOfContents: true
updatedOn: '2026-02-06T22:07:33.063Z'
---

<InfoBlock>
<DocsList title="What you will learn:" >
<a href="#the-core-change-connection-pooling">What connection pooling is and why it mattered for serverless</a>
<a href="#the-two-scenarios-classic-serverless-versus-fluid-compute">The difference between "Classic Serverless" and Vercel's "Fluid compute"</a>
<a href="#comparison-of-connection-methods">How TCP, HTTP, and WebSocket connections compare on latency</a>
<a href="#our-recommendation">Our recommendation for connecting from Vercel</a>
</DocsList>

<DocsList title="Related topics" theme="docs">
<a href="/docs/guides/vercel-managed-integration">Vercel-Managed Integration</a>
<a href="/docs/guides/neon-managed-vercel-integration">Neon-Managed Integration</a>
<a href="/docs/guides/benchmarking-latency">Benchmarking latency</a>
</DocsList>
</InfoBlock>

---

## Connecting to Neon from Vercel: Understanding Fluid compute

Vercel's **Fluid** compute model fundamentally changes the performance trade-offs for connecting to your Neon database.

**The short answer:** With Vercel Fluid, we recommend you use a **standard Postgres TCP connection** (e.g., with the [node-postgres package](https://node-postgres.com/)) and a connection pool. This is the new fastest and most robust method.

This guide explains why this is a change, the difference between connection methods, and what you should use.

---

## The core change: Connection pooling

The most important concept to understand is **connection pooling**.

- **Database connection:** Establishing a connection to a Postgres database is an expensive, multi-step process (called a "handshake") that takes time.
- **Connection pooling:** A connection pool is a "cache" of active database connections. When your function needs to talk to the database, it quickly grabs a connection from the pool, uses it, and then returns it (also quickly).

The key problem with "classic" serverless was that you could not safely maintain a connection pool. Functions would be suspended while holding idle connections, leading to "leaks" that could exhaust your database's connection limit.

---

## The two scenarios: Classic serverless versus Fluid compute

How you connect depends entirely on your compute environment.

### Classic serverless (the "old way")

In a traditional serverless environment, each request spins up a new, isolated function instance. That instance runs its code and then shuts down.

- **The problem:** Because connection pools were not safe (as noted above), you had to establish a _new_ database connection on _every single request_.
- **The latency hit:** A standard TCP connection (the default for Postgres) takes the most "roundtrips" (~8) to establish. This adds significant latency to _every API call_.
- **The solution (HTTP/WebSocket):** To solve this, Neon provides the [@neondatabase/serverless](/docs/serverless/serverless-driver) driver, which connects over HTTP or WebSockets. These protocols have _fewer setup roundtrips_ (~3-4), making them much faster _for the first query_.

### Vercel Fluid compute (the "new way")

Vercel's Fluid model allows function runs to _reuse warm compute instances_ and share resources.

- **The opportunity:** This reuse is the key. It makes **connection pooling possible and safe** in a serverless environment.
- **How Fluid makes pooling safe:** Vercel Fluid solves the "leaked connection" problem. It keeps a function alive _just long enough_ to safely close idle connections _before_ the function is suspended, making pooling reliable.
- **The new "fastest" method:** You can now establish a TCP connection _once_ and place it in a pool. Subsequent function calls reuse that "warm" connection, skipping the ~8 roundtrip setup cost entirely.
- **The result:** Once the connection is established, a direct Postgres TCP connection is the lowest-latency and most performant way to query your database.

---

## Comparison of connection methods

This table breaks down the trade-offs, which are all about setup cost versus query speed.

| Connection Method  | Protocol      | Setup Cost (Roundtrips) | Best For...                                                                                           |
| :----------------- | :------------ | :---------------------- | :---------------------------------------------------------------------------------------------------- |
| **Postgres (TCP)** | `postgres://` | High (~8)               | **Fluid compute / Long-running servers.** (Render, Railway). Once established, it's the fastest.      |
| **HTTP**           | `http://`     | Lowest (~3)             | **Classic Serverless.** Fastest for a _single query_ where you can't pool connections.                |
| **WebSocket**      | `ws://`       | Low (~4)                | **Classic Serverless.** A good alternative to HTTP, especially in environments that don't support it. |

_Note: Roundtrip counts are estimates and vary based on authentication and configuration._

---

## Our recommendation

### If you are using Vercel's Fluid compute:

We recommend using a standard Postgres TCP driver (like [node-postgres](https://node-postgres.com/)) and implementing a connection pool. This will give you the best performance by paying the connection cost once and reusing the connection for subsequent queries. See Vercel's [Connection pooling with Vercel Functions](https://vercel.com/guides/connection-pooling-with-functions) guide for implementation details.

<Admonition type="note" title="A note on benchmarking">
Before migrating, we recommend you benchmark both connection methods on your own app. While TCP with pooling is the new default, some applications with a very high number of cold starts might, in edge cases, still see an advantage from the low initial connection time of the HTTP driver.
</Admonition>

### If you are on a "classic" serverless platform (without connection pooling):

Continue using the [@neondatabase/serverless](/docs/serverless/serverless-driver) driver. Its HTTP-based connection is optimized for low-latency "first queries," which is the most important metric in that environment.

You can see a live latency comparison of these three methods here: [Function latency comparison](https://function-database-latency-sigma.vercel.app)
