Neon Serverless Driver: Query Postgres over HTTP (2026)

The Neon Serverless Driver lets you query Postgres databases over HTTP, bypassing the need for traditional TCP connections and their associated overhead.

Imagine you’re building a web application and need to talk to your Postgres database. Traditionally, your app would open a persistent TCP connection to the database server. This works fine for a single server, but in a serverless environment where your application’s compute instances spin up and down rapidly, managing thousands of these long-lived TCP connections can become a massive bottleneck. Each connection consumes resources on both the client and server, and establishing them takes time.

The Neon Serverless Driver flips this on its head. Instead of a direct TCP connection, it uses HTTP/2 to communicate with Neon’s specialized proxy. This proxy acts as an intermediary, efficiently managing a pool of actual Postgres connections and multiplexing requests from many serverless clients over a few HTTP/2 streams.

Let’s see it in action. Here’s a simplified JavaScript example using the driver:

import neon from '@neondatabase/serverless';

async function queryDatabase() {
  const pool = new neon.Pool({
    connectionString: `postgresql://${process.env.PGUSER}:${process.env.PGPASSWORD}@${process.env.PGHOST}/${process.env.PGDATABASE}?sslmode=require`,
  });

  try {
    const result = await pool.query('SELECT NOW()');
    console.log('Current time from Postgres:', result.rows[0].now);
  } catch (error) {
    console.error('Error querying database:', error);
  } finally {
    await pool.end();
  }
}

queryDatabase();

In this snippet:

• We import the neon library.
• We create a neon.Pool. Crucially, the connectionString here points to Neon’s HTTP-enabled endpoint, not a direct Postgres TCP port. The sslmode=require is essential for secure communication.
• We execute a simple SELECT NOW() query. The driver, behind the scenes, translates this into an HTTP/2 request to the Neon proxy.
• The proxy receives the request, establishes or reuses an underlying Postgres connection, sends the query, gets the result, and sends it back to your application over HTTP/2.
• Finally, pool.end() gracefully closes the driver’s HTTP/2 session.

The core problem this solves is connection management at scale for serverless. Serverless functions are designed to be ephemeral. If each function instance spun up a new, dedicated TCP connection to Postgres, you’d quickly exhaust connection limits on the database and experience high latency due to connection setup time. The Neon Serverless Driver, by using HTTP/2 and a smart proxy, allows a vast number of serverless functions to share a much smaller number of actual Postgres connections. The proxy handles the heavy lifting of connection pooling and multiplexing, presenting a lightweight, stateless interface to your serverless environment.

The connectionString you use is key. It doesn’t point to the standard Postgres port (5432) but rather to the HTTP endpoint provided by Neon. This endpoint is managed by Neon’s infrastructure and is designed to handle the HTTP/2 protocol. The sslmode=require isn’t just about encryption; it’s often part of how the driver and proxy negotiate the HTTP/2 connection.

When you query, the driver serializes your SQL statement and sends it as an HTTP/2 POST request to the Neon endpoint. The Neon proxy receives this, decodes the HTTP/2 frame, and then uses a pre-existing, pooled TCP connection to send the actual Postgres query to your database. The result travels back through the proxy, is re-serialized into an HTTP/2 response, and sent back to your driver. This entire process is designed to be low-latency and efficient for short-lived, high-frequency requests typical of serverless workloads.

What most people don’t realize is how the driver handles the Postgres wire protocol over HTTP/2. It doesn’t just tunnel raw TCP. Instead, it breaks down the Postgres protocol messages into smaller chunks that fit within HTTP/2 frames and uses the stream multiplexing capabilities of HTTP/2 to interleave multiple requests and responses from different logical Postgres sessions over a single underlying connection between the driver and the proxy. This means that even though your application might appear to have many "connections" from the driver’s perspective, the actual number of TCP connections to the Postgres backend is kept to a minimum by the Neon proxy.

The next step is understanding how Neon’s branch-based architecture integrates with this driver for development and testing workflows.