Neon Functions

Neon Functions put your backend code on a Neon branch, in the same region as your data. Use them for APIs, AI agents, real-time servers, and webhook handlers, with no servers to set up or manage. They're long-running, and branch with your database, so each branch runs its own copy of your functions against its own data.

What makes Neon Functions different from lambda-style serverless?

• Next to your data. A function runs in the same region as its branch, so queries reach Postgres with no cross-region hops.
• Long-running. Start responding within 15 minutes, then keep streaming while data flows, so agents and WebSocket/SSE servers aren't cut off by a short execution limit. They're still serverless: idle functions can be evicted (see Runtime limits).
• Branch-scoped. Functions branch with your project. Each branch runs its own deployment of them, at branch-specific URLs, against that branch's data.
• Event-driven. Invoke a function on a cron schedule or an object upload with Function Triggers, no external scheduler.

Functions run on Neon's own compute platform, the same infrastructure that runs your Postgres.

Functions are currently available in AWS US East (Ohio) (aws-us-east-2), AWS US East (N. Virginia) (aws-us-east-1), AWS Europe (Frankfurt) (aws-eu-central-1), and AWS Asia Pacific (Singapore) (aws-ap-southeast-1). Create your project in one of these regions to use them. Support is expanding toward all regions. Functions are available on any plan, subject to usage limits. See plans and pricing for rates.

A function always runs in response to a request and returns a web response: JSON, an HTTP stream, an SSE feed, or a WebSocket upgrade. The request usually comes from a client (a fetch, a browser, an agent), but it can also come from Neon: a Function Trigger invokes the function on a cron schedule.

Functions fit request/response work, including scheduled runs with Function Triggers. They aren't a job queue. Queued, retryable, cancellable work with its own lifecycle, like sending a welcome email after signup, still needs a queue or workflow engine to own that lifecycle. You can pair a function with a third-party queue like Upstash QStash or Inngest, which owns the queue and retries and invokes your function over HTTP. A native Neon job queue and workflow engine is a separate, upcoming offering.

Any module whose default export provides a fetch(request) method that returns a Response is a function. It embraces the web platform standards: the Fetch API's Request and Response interface, the same handler shape used by other serverless runtimes and standardized by WinterTC. That can be an object with a fetch method:

export default {
  fetch: (request: Request) => new Response('Hello world'),
};

Or a bare async function:

export default async function handler(request: Request) {
  return new Response('Hello world');
}

A Hono app exports the object shape, so export default app works directly. Hono is the recommended framework.

• REST APIs and CRUD backends: request in, JSON out, queries running next to Postgres. See Quickstart.
• AI agents: stream tokens back across multiple model calls and tool invocations without a short execution limit cutting the run off. See AI agents.
• Real-time apps: WebSocket servers for chat and presence, or SSE for live updates. See WebSockets and SSE.
• MCP servers: expose database-backed tools to AI clients over a single fetch endpoint. See the with-mcp example.
• File upload APIs: receive a file, write it to Object Storage, return a result.
• Webhook handlers and bots: receive events and query Postgres in the same region.
• Scheduled and event-driven jobs: run a function on a cron schedule or when a file lands in Object Storage, with no external scheduler. See Function Triggers.

Functions are backend primitives, not full-stack app hosting. Host your app on Vercel, Netlify, or another frontend host; reach for a function for the long-running, stateful slice of your backend that belongs next to your data. Two common shapes:

• Add a function to a full-stack app. Your Next.js or TanStack Start app owns the UI, auth, and most routes. When one workload outgrows the host's short serverless limit (a WebSocket or SSE server, or a long-running agent), move only that piece onto a function and call it directly from the client. See Authentication for the direct-call pattern.
• Run the backend on functions. When the frontend is client-only (a React or TanStack SPA), the client calls functions directly: REST APIs, request/response agents, MCP servers, and anything stateful that belongs close to Postgres and Object Storage.

Each example is a complete, runnable build. Read the source on GitHub, or scaffold one with neon bootstrap --template <id> (it copies the files, links a Neon project, and pulls env vars). You can also browse them at build-on-neon.vercel.app.

Join our Discord Server to ask questions or see what others are doing with Neon. For paid plan support options, see Support.