When Neon first launched in 2022, there was a gap between how fast teams were moving and what Postgres let them do. Compute and storage were welded together into a monolith, and every copy of a database was expensive to create, slow to spin up, and painful to throw away. It was already the era of GitHub, Vercel, automated CI/CD. Teams wanted their database to move as smoothly as the rest of their stack but were stuck with an outdated design.

To close that gap, we rebuilt the architecture underneath Postgres, pioneering what would later become the lakebase architecture. We kept 100% of Postgres but we separated compute from a distributed, versioned object storage engine. From this foundation, we were able to build features that gave the database a modern DX experience, like instant provisioning, real-time autoscaling, scale to zero, and branching.

Postgres was finally catching up with how developers worked. And then agents came along.

Agents are the ones building now. They need backend primitives

The other side of the Neon API are now agents acting on behalf of developers. Giving Postgres the right DX turned out to be the perfect starting point to provide a great AX, but when agents build apps they don't build on databases alone - they deploy backends.

When a coding agent ships an app it deploys Postgres and a set of tooling around it. Apps need to store uploads, run jobs that touch that data, authenticate users, call AI models. If those are wired up as separate services on top of the Neon database, the Neon experience breaks - the bucket points at production from every branch, the function doesn't know the branch exists, auth users live in a different system, and so on. This is not the right AX, so we're building these tools ourselves from the same semantics as Lakebase Postgres, our database.

When we say "we're building backends", we think of "backend" as a set of solid primitives an agent can call, not a bundle of managed services behind one bill. The distinction is deliberate. A backend-as-a-service bundles features and asks you to adopt its way of doing things. That is not what we're building.

The reason comes down to how agents write software. An agent is good at composing primitives it already understands: Postgres, an S3 API, a standard model SDK. Give it well-established pieces with predictable interfaces and it might get the app right on the first try. Auth and ORMs already showed the pattern: Better Auth gave agents a primitive they reach for by default, Drizzle did the same for the ORM, and the code comes out right because the primitive is solid. Your entire backend should work the same way.

We're building our backend as a set of primitives, each with a standard interface and an understanding of the Neon design principles: infra that adapts to the workload, instant deploys and restores, and branching-first, agents-first workflows. Nothing here asks you to learn a proprietary framework or trades your data for convenience, and you can point standard tools at any of it and leave whenever you want. But the primitives compose, and an agent can wire them together through one interface to build solid foundations for software.

What's included in Neon

A full walkthrough:

Lakebase Postgres

Postgres at the center, setting up the stage for all workflows.

> Create a Neon database for my app. Make the main branch autoscale up to 8 CU, make sure it suspends after 5 minutes of inactivity.

import { defineConfig } from "@neon/config/v1";

export default defineConfig({
  branch: (branch) => {
    if (branch.isDefault) {
      return {
        postgres: {
          computeSettings: {
            autoscalingLimitMinCu: 0.25,
            autoscalingLimitMaxCu: 8,
            suspendTimeout: "5m",
          },
        },
      };
    }
    return {};
  },
});

The Neon database you already know:

• 100% Postgres, with the lakebase architecture - compute is separated from versioned, copy-on-write object storage
• Compute provisions instantly, autoscales within limits you set, and suspends when idle
• Branching gives every pull request, preview, dev environment, test run, or agent session an isolated copy of the database that's available instantly
• Query it over HTTP with a PostgREST-compatible interface
• Run it with your agent

Object Storage

S3-compatible object storage that branches with your data.

> Add a private bucket called `uploads` to this Neon backend. Keep it on the same branch as the database so preview uploads cannot change production files.

import { defineConfig } from "@neon/config/v1";

export default defineConfig({
  buckets: {
    uploads: { access: "public_read" },
  },
});

Your files now follow your database as you branch:

• Every Neon branch reflects a perfect copy of its parent's buckets and objects at the moment it is created
• But data is not duplicated: even if your bucket is huge, you don't pay for more storage just because you're branching
• Any file changes on the child branch stay isolated from the parent
• Standard S3 clients work

Functions

Long-running Node.js compute for those jobs touching Postgres.

> Add a function that reads an uploaded file and records its status in Postgres.

import { defineConfig } from "@neon/config/v1";

export default defineConfig({
  functions: {
    processupload: {
      name: "Process upload",
      source: "./functions/process-upload.ts",
    },
  },
});

Serverless functions you can deploy right next to Postgres:

• Node.js 24 HTTP handlers run on the same branch and in the same region as your database, with DATABASE_URL and credentials for other Neon primitives injected automatically
• Long-running enough for agents and realtime
• [Just shipped] You can use Function Triggers for scheduled triggers (docs)
• [Just shipped] We also support custom domains (docs)

Managed Better Auth

Auth that branches, with the Better Auth code you know.

> Add Managed Better Auth to this app and use it as the identity provider.

import { defineConfig } from "@neon/config/v1";

export default defineConfig({
  auth: true,
});

Your auth lives next to your database and branches with it:

• Users, sessions, organizations, and configuration live in the neon_auth schema, where they can be queried with SQL and used with RLS
• When the database branches, its auth state branches too, so preview signups reflect production accurately
• It uses Better Auth APIs and schema: agents work with an established auth primitive instead of a proprietary identity model

AI Gateway

Frontier and open-weight models powered by Databricks Foundation APIs.

> Use Neon AI Gateway for model calls. Keep the model configurable so I can test another model in a preview branch without changing production.

import { defineConfig } from "@neon/config/v1";

export default defineConfig({
  aiGateway: true,
});

You can call AI models directly from Neon:

• A branch-scoped Neon credential reaches models from multiple providers. An agent can switch models without provisioning a separate provider account and key each time
• Models are served through Databricks Foundation Model APIs
• We pass through the labs' published per-token price with no additional markup

What's next

Our backend will keep growing on the same foundation. The Electric team, who built PGlite and the Electric sync engine, is now part of Neon, and realtime is exactly the kind of primitive agents should be able to find on Neon. We'll share more soon.

In the meantime, we want to see what you build with these tools. Tag us on X, send us feedback, and tell us what to improve. We're in Discord too.