Neon has launched Functions, a serverless Node.js 24 compute layer that deploys directly onto a Neon Postgres branch in the same region as the database, with DATABASE_URL and other backend credentials (Object Storage, AI Gateway, Auth) injected automatically. Unlike typical Lambda-style handlers, Neon Functions are long-running, supporting minutes-long agent tool loops, WebSockets, and SSE, and they branch alongside the rest of the Neon stack - creating a child branch spins up an isolated copy of the function too. Functions are declared via neon.ts (Neon's backend-as-code config), any module exporting a fetch(request) handler works, and Hono is the recommended framework; a long-lived pg Pool is recommended over the edge-oriented @neondatabase/serverless driver. Functions are not meant for hosting full frontends or background jobs (pair with something like Inngest for queued work), and are free during the current beta. Scheduled/event-based triggers (cron, storage events, auth/database events) are coming soon.
Table of contents
If the job involves the database, run the function next to itLong-running for agents and realtimeFunctions branch like the rest of your stackDeclaring FunctionsComing soon: schedules and triggers for your FunctionsA few examples: building with functionsDeploy one and poke itQuestions this post answers
What is Neon Functions and how does it differ from a typical serverless API handler?
Neon Functions is Node.js 24 compute that deploys directly onto a Neon Postgres branch in the same region as the database, with DATABASE_URL and other Neon backend credentials (Object Storage, AI Gateway, Auth) injected automatically. Unlike typical Lambda-style handlers that talk to a database over the public internet with short runtime caps, Neon Functions are long-running, letting agents stream for minutes and WebSockets or SSE connections stay open. Teams evaluating serverless backends for AI agents can track releases like this one on daily.dev.
Should I use the Neon serverless driver or pg Pool inside a Neon Function?
Use pg Pool, not the @neondatabase/serverless driver, inside a Neon Function. The serverless driver is built for short-lived, edge-style invocations, whereas a Neon Function stays running across requests, so creating a pg Pool once at module scope and reusing it is the recommended pattern. Developers wiring up Postgres connections in new runtimes can keep tabs on guidance like this via daily.dev.
Do Neon Functions support background jobs or scheduled tasks?
No, a Neon Function is always request-driven and must return a web response (JSON, a stream, SSE, or a WebSocket upgrade) - it is not a background job runner. For queued work with its own lifecycle, pairing a function with a tool like Inngest is recommended, while native cron and event-based triggers (storage, auth, database events) are planned but not yet available. Anyone weighing scheduler and background-job options for a new backend can follow updates like this on daily.dev.
92.2K Impressions3 Comments