Neon Object Storage, Functions, and AI Gateway have graduated from private preview to beta

Neon Object Storage, Functions, and AI Gateway have graduated from private preview to beta. Everyone can start building a complete backend on new or existing projects in AWS US East (Ohio) today.

Declare your whole backend in one neon.ts file, and it branches with your data. Fork a branch and you get an isolated copy of your database, files, functions, and gateway.

• Object Storage: S3-compatible object storage that branches with your database.
• Functions: Long-running serverless compute that runs alongside your database.
• AI Gateway: One API for frontier and open-source models, built into your project.

New to the Neon backend? Start with the beta guide, see how the pieces fit together, or build one end to end with the full backend quickstart. For the vision behind the platform, read the announcement blog post.

ONE-SHOT YOUR BACKEND WITH AN AI AGENT

Install the beta agent skills:

npx neon@latest init --preview

Then build your backend from a single prompt:

Set up a Neon backend for my app with Postgres, object storage, functions, and AI gateway

Your agent provisions the services, declares them in neon.ts, and wires them into your app.

New TypeScript SDK for the Neon API

We're introducing @neon/sdk 1.1, the best way to work with the Neon API from TypeScript. It's fetch-based, zero-dependency, and generated from our OpenAPI spec, with an ergonomic layer on top. It covers the whole Neon Platform API: projects, branches, databases, and our new backend services (Object Storage, Functions, and AI Gateway). It replaces @neondatabase/api-client as the recommended client, though the legacy package still works.

The ergonomic layer matters most for the multi-step provisioning workflows that might take you or your agent a few attempts to get right (for example, create a project, wait for it to be ready, then create a branch and hand back a connection string). createNeonClient({ apiKey }) gives you namespaced methods (neon.projects, neon.storage, neon.functions, neon.aiGateway, and more), typed { data, error } results, and workflow helpers like createAndConnect. Any method takes { waitForReadiness: true } to block until provisioning finishes, and a raw layer exposes every endpoint.

Read the announcement blog post for the full story, or see the TypeScript SDK documentation and migration guide for setup, API reference, and moving from @neondatabase/api-client.

Passkey support

You can now sign in to Neon with a passkey instead of a 2FA code. Add a passkey from Account settings and use your device's built-in biometrics, like Touch ID or Windows Hello, or a security key to verify it's you. Passkeys satisfy organization-level 2FA requirements, so admins can let members enroll in either 2FA or a passkey to comply. See Manage your Neon account for setup steps.

Git-style diffs in the Neon CLI

New neon diff command

We've added a top-level diff command to the Neon CLI, letting you (and your agents) quickly see schema changes between your current branch and any other branch you specify. It fits into a branch-first development workflow alongside neon link, neon checkout, neon status, and neon deploy.

Want your agents to use neon diff? Install the Neon agent skills so your assistant has current knowledge of the CLI and reaches for the command on its own:

npx neon@latest init

Config commands now show the same diff

neon.ts is the TypeScript config file that declares your Neon backend: which services are on (Postgres, Auth, Data API, Object Storage, Functions) and your branch settings (compute size, TTL, protected). The config commands reconcile that file with what's actually live: neon config plan previews the changes, neon config apply makes them, and neon deploy applies and provisions in one step.

These commands now report their changes as a git diff instead of tables so you can see exactly what will change before you confirm.

New NAT gateway IPs and VPC endpoint services in US East (Ohio), Europe (London), and Asia Pacific (Singapore)

We've expanded infrastructure capacity in the AWS US East (Ohio) (us-east-2), Europe (London) (eu-west-2), and Asia Pacific (Singapore) (ap-southeast-1) regions with new NAT gateway IP addresses and new VPC endpoint service addresses for Private Networking.

UPDATE YOUR IP ALLOWLISTS

If you have IP allowlists on external systems that Neon connects to, update those allowlists to include the new NAT gateway addresses. Connections may be affected intermittently if traffic routes through non-allowlisted NAT gateways.

If you use Private Networking in these regions, you can now use the additional VPC endpoint service addresses for enhanced capacity and reliability. See the Regions documentation for the complete list of NAT gateway IPs and the Private Networking guide for VPC endpoint service addresses by region.

Original source

Neon backend for apps and agents is now in beta

Neon Object Storage, Functions, and AI Gateway have graduated from private preview to beta. Everyone can start building a complete backend on new or existing projects in AWS US East (Ohio) today.

Declare your whole backend in one neon.ts file, and it branches with your data. Fork a branch and you get an isolated copy of your database, files, functions, and gateway.

• Object Storage: S3-compatible object storage that branches with your database.
• Functions: Long-running serverless compute that runs alongside your database.
• AI Gateway: One API for frontier and open-source models, built into your project.

New to the Neon backend? Start with the beta guide, see how the pieces fit together, or build one end to end with the full backend quickstart. For the vision behind the platform, read the announcement blog post.

ONE-SHOT YOUR BACKEND WITH AN AI AGENT

Install the beta agent skills:

npx neon@latest init --preview

Then build your backend from a single prompt:

Set up a Neon backend for my app with Postgres, object storage, functions, and AI gateway

Your agent provisions the services, declares them in neon.ts, and wires them into your app.

New TypeScript SDK for the Neon API

We're introducing @neon/sdk 1.1, the best way to work with the Neon API from TypeScript. It's fetch-based, zero-dependency, and generated from our OpenAPI spec, with an ergonomic layer on top. It covers the whole Neon Platform API: projects, branches, databases, and our new backend services (Object Storage, Functions, and AI Gateway). It replaces @neondatabase/api-client as the recommended client, though the legacy package still works.

The ergonomic layer matters most for the multi-step provisioning workflows that might take you or your agent a few attempts to get right (for example, create a project, wait for it to be ready, then create a branch and hand back a connection string).

createNeonClient({ apiKey }) gives you namespaced methods (neon.projects, neon.storage, neon.functions, neon.aiGateway, and more), typed { data, error } results, and workflow helpers like createAndConnect. Any method takes { waitForReadiness: true } to block until provisioning finishes, and a raw layer exposes every endpoint.

npm install @neon/sdk

import { createNeonClient } from "@neon/sdk";
const neon = createNeonClient({ apiKey: process.env.NEON_API_KEY! });

// Workflow helper: create, poll until ready, return a connection string
const { data, error } = await neon.projects.createAndConnect({ name: "my-app" });
if (error) throw error;
const { project, connectionString } = data;

// Or wait on any mutation with waitForReadiness
const { data: branch, error: branchError } = await neon.branches.create(
  project.id,
  { name: "preview" },
  { waitForReadiness: true }
);
if (branchError) throw branchError;

// The new backend services are namespaced too
await neon.storage.buckets.create(
  project.id,
  branch.id,
  { name: "uploads" }
);

Read the announcement blog post for the full story, or see the TypeScript SDK documentation and migration guide for setup, API reference, and moving from @neondatabase/api-client.

Passkey support

You can now sign in to Neon with a passkey instead of a 2FA code. Add a passkey from Account settings and use your device's built-in biometrics, like Touch ID or Windows Hello, or a security key to verify it's you. Passkeys satisfy organization-level 2FA requirements, so admins can let members enroll in either 2FA or a passkey to comply. See Manage your Neon account for setup steps.

Git-style diffs in the Neon CLI

New neon diff command

We've added a top-level diff command to the Neon CLI, letting you (and your agents) quickly see schema changes between your current branch and any other branch you specify. It fits into a branch-first development workflow alongside neon link, neon checkout, neon status, and neon deploy.

1. neon link: link to a Neon project
2. neon checkout dev-1: create/checkout a dev branch
3. Do the dev work
4. neon diff main: sanity check the schema changes made against main

Want your agents to use neon diff? Install the Neon agent skills so your assistant has current knowledge of the CLI and reaches for the command on its own:

npx neon@latest init

Config commands now show the same diff

neon.ts is the TypeScript config file that declares your Neon backend: which services are on (Postgres, Auth, Data API, Object Storage, Functions) and your branch settings (compute size, TTL, protected). The config commands reconcile that file with what's actually live: neon config plan previews the changes, neon config apply makes them, and neon deploy applies and provisions in one step.

These commands now report their changes as a git diff instead of tables so you can see exactly what will change before you confirm:

If apply finds a setting that already differs on the branch, it shows the current value too and stops without changing anything until you re-run with --update-existing.

New NAT gateway IPs and VPC endpoint services in US East (Ohio), Europe (London), and Asia Pacific (Singapore)

We've expanded infrastructure capacity in the AWS US East (Ohio) (us-east-2), Europe (London) (eu-west-2), and Asia Pacific (Singapore) (ap-southeast-1) regions with new NAT gateway IP addresses and new VPC endpoint service addresses for Private Networking.

UPDATE YOUR IP ALLOWLISTS

If you have IP allowlists on external systems that Neon connects to, update those allowlists to include the new NAT gateway addresses. Connections may be affected intermittently if traffic routes through non-allowlisted NAT gateways.

If you use Private Networking in these regions, you can now use the additional VPC endpoint service addresses for enhanced capacity and reliability. See the Regions documentation for the complete list of NAT gateway IPs and the Private Networking guide for VPC endpoint service addresses by region.

Original source

New neon api command in the Neon CLI

The Neon CLI now ships an api command: call any Neon Platform API route from the terminal using your existing CLI login, without hand-building curl requests or giving agents raw API keys.

Dedicated CLI commands cover common workflows, but the Platform API moves faster. With the neon api command, you get full API reach the moment an endpoint exists. Run neon api --list to browse every route from the OpenAPI spec.

Read the announcement for why we built this for agent workflows.

List projects for your organization:

neon orgs list
neon api /projects -Q org_id=org-cool-darkness-12345678

Create a dev branch on an existing project:

neon api /projects/late-frost-12345678/branches -X POST -F branch.name=dev

The -F branch.name=dev flag builds the JSON body { "branch": { "name": "dev" } } automatically. See the api command reference for query parameters, file bodies (-d @file), and output formats.

Cmd+K support for the Neon Console

You can now press Cmd+K (Mac) or Ctrl+K (Windows/Linux) from anywhere in the Neon Console to open a searchable command bar with actions scoped to your current branch and project: navigate to branches, open the SQL editor, create a snapshot, go to settings, and more.

Neon MCP Server: branch expiration on create

The Neon MCP Server create_branch tool now accepts an optional expiresAt parameter (ISO 8601) to set automatic branch deletion when creating a branch, matching the Neon API and console Auto-delete behavior. See branch expiration.

Connect the MCP Server in your editor:

npx add-mcp https://mcp.neon.tech/mcp

For full setup (API key auth, agent skills, and more), run npx neon@latest init. See Connect MCP clients to Neon.

New NAT gateway IPs and VPC endpoint services in US East (Ohio), Europe (London), and Asia Pacific (Singapore)

We've expanded infrastructure capacity in the AWS US East (Ohio) (us-east-2), Europe (London) (eu-west-2), and Asia Pacific (Singapore) (ap-southeast-1) regions with new NAT gateway IP addresses and new VPC endpoint service addresses for Private Networking.

UPDATE YOUR IP ALLOWLISTS

If you have IP allowlists on external systems that Neon connects to, update those allowlists to include the new NAT gateway addresses. Connections may be affected intermittently if traffic routes through non-allowlisted NAT gateways.

If you use Private Networking in these regions, you can now use the additional VPC endpoint service addresses for enhanced capacity and reliability. See the Regions documentation for the complete list of NAT gateway IPs and the Private Networking guide for VPC endpoint service addresses by region.

Postgres turns 30

Postgres turned 30 on July 8. See our post on X.

Neon is a long-term bet on Postgres. We support Postgres 14 through 18 today, with Postgres 19 support on the way. Our team includes Postgres hackers who contribute upstream and support the wider ecosystem through our Open Source Program. We run standard Postgres, not a fork: Neon is Postgres, with serverless branching and autoscaling built around the database millions of developers already rely on.

Happy birthday, Postgres. 🎂🐘

Original source

New neon api command in the Neon CLI

The Neon CLI now ships an api command: call any Neon Platform API route from the terminal using your existing CLI login, without hand-building curl requests or giving agents raw API keys.

Dedicated CLI commands cover common workflows, but the Platform API moves faster. With the neon api command, you get full API reach the moment an endpoint exists. Run neon api --list to browse every route from the OpenAPI spec.

Read the announcement for why we built this for agent workflows.

List projects for your organization:

neon orgs list
neon api /projects -Q org_id=org-cool-darkness-12345678

Create a dev branch on an existing project:

neon api /projects/late-frost-12345678/branches -X POST -F branch.name=dev

The -F branch.name=dev flag builds the JSON body { "branch": { "name": "dev" } } automatically. See the api command reference for query parameters, file bodies (-d @file), and output formats.

Cmd+K support for the Neon Console

You can now press Cmd+K (Mac) or Ctrl+K (Windows/Linux) from anywhere in the Neon Console to open a searchable command bar with actions scoped to your current branch and project: navigate to branches, open the SQL editor, create a snapshot, go to settings, and more.

Neon MCP Server: branch expiration on create

The Neon MCP Server create_branch tool now accepts an optional expiresAt parameter (ISO 8601) to set automatic branch deletion when creating a branch, matching the Neon API and console Auto-delete behavior. See branch expiration.

Connect the MCP Server in your editor:

npx add-mcp https://mcp.neon.tech/mcp

For full setup (API key auth, agent skills, and more), run npx neon@latest init. See Connect MCP clients to Neon.

New NAT gateway IPs and VPC endpoint services in US East (Ohio), Europe (London), and Asia Pacific (Singapore)

We've expanded infrastructure capacity in the AWS US East (Ohio) (us-east-2), Europe (London) (eu-west-2), and Asia Pacific (Singapore) (ap-southeast-1) regions with new NAT gateway IP addresses and new VPC endpoint service addresses for Private Networking.

UPDATE YOUR IP ALLOWLISTS

If you have IP allowlists on external systems that Neon connects to, update those allowlists to include the new NAT gateway addresses. Connections may be affected intermittently if traffic routes through non-allowlisted NAT gateways.

If you use Private Networking in these regions, you can now use the additional VPC endpoint service addresses for enhanced capacity and reliability. See the Regions documentation for the complete list of NAT gateway IPs and the Private Networking guide for VPC endpoint service addresses by region.

Postgres turns 30

Postgres turned 30 on July 8. See our post on X.

Neon is a long-term bet on Postgres. We support Postgres 14 through 18 today, with Postgres 19 support on the way. Our team includes Postgres hackers who contribute upstream and support the wider ecosystem through our Open Source Program. We run standard Postgres, not a fork: Neon is Postgres, with serverless branching and autoscaling built around the database millions of developers already rely on.

Happy birthday, Postgres. 🎂🐘

Original source

Neon CLI enhancements

We're continually improving the Neon CLI and the developer experience around it. Recent additions include neon link, neon checkout, and neon env pull commands and neon.ts. This week brings a shorter name plus two additional commands.

• The CLI is now just neon

You can now install the Neon CLI from npm as neon instead of neonctl: npm i -g neon (or run it with npx neon@latest). All commands are now documented as neon rather than neonctl. If you already use neonctl, nothing changes: it's the same CLI, neonctl still works as a command, and no migration or re-authentication is needed. See the Neon CLI install guide.

The latest CLI now requires Node.js 20.19.0 or higher (previously 18). An existing installation keeps working on your current Node.js version; if you're on an older version, upgrade Node.js before updating the CLI.

• Set up declarative branch management in one step

The new neon config init command scaffolds a starter neon.ts config file and installs the @neon/config and @neon/env packages, so you can define how each branch is set up (compute size, scale-to-zero, TTL, and which services it uses) declaratively, without any manual setup. It runs entirely locally, and neon link now offers to run it as its final step.

• Check your current branch instantly, with no network call

The new neon status command is a top-level alias for neon config status. Add --current-branch to print just the branch pinned in your local .neon file:

neon status --current-branch

Because it makes no network call, it's fast enough to run on every shell prompt. For example, add your current Neon branch to a starship prompt by appending this [custom.neon] module to ~/.config/starship.toml:

# ~/.config/starship.toml
[custom.neon]
description = "Current Neon branch"
command = "neon status --current-branch" # prints the branch pinned in .neon (no network)
when = "neon status --current-branch" # exits non-zero when no branch -> segment is hidden
symbol = "🌿 "
style = "bold green"
format = "[$symbol$output]($style) "

See the config command reference for more.

Neon Storage in the Files SDK

Neon Storage now has a first-class adapter in the Files SDK, the open-source library that gives you one upload, download, and presigned-URL API across S3, R2, GCS, and more. The neon adapter is wired up from the AWS_* variables Neon injects, so pointing your storage backend at Neon is a one-line config change:

import { Files } from 'files-sdk';
import { neon } from 'files-sdk/neon';
const files = new Files({ adapter: neon({ bucket: 'assets' }) });

// Upload a file, then get a presigned URL to view it
await files.upload('logos/neon-logo.png', body, { contentType: 'image/png' });
const url = await files.url('logos/neon-logo.png', { expiresIn: 3600 });

See the with-files-sdk example for a minimal script that uploads files to a branch-scoped bucket.

Neon Storage is part of Neon's new backend services, currently in private preview. If you haven't signed up yet, you can sign up and learn more.

Learn more about Lakebase Search

We recently opened Lakebase Search to all Neon users, adding scalable vector, keyword, and hybrid search to Postgres through the lakebase_vector and lakebase_text extensions. This week, our engineering team goes under the hood.

Read Lakebase Search: vector and BM25 on Neon blog post to learn why the usual pgvector + GIN setup breaks down at scale, and how lakebase_ann (IVF + RaBitQ) and lakebase_bm25 (Block-Max WAND) keep indexes on object storage so they stay ready across scale-to-zero and branching.

Update snapshot expiration anytime

You can now update a snapshot's expiration with the Update snapshot endpoint. Set expires_at to a future timestamp to change the retention deadline, or send null to remove it so the snapshot never expires. Previously, expiration could only be set when the snapshot was created.

curl --request PATCH \
--url 'https://console.neon.tech/api/v2/projects/{project_id}/snapshots/{snapshot_id}' \
--header 'authorization: Bearer $NEON_API_KEY' \
--header 'content-type: application/json' \
--data '{
  "snapshot": {
    "expires_at": "2026-12-31T00:00:00Z"
  }
}'

Planned update notifications change

So that we can ship Neon improvements and fixes faster, the advance notice period for planned updates on the Scale and Enterprise plans is changing from 7 days to 3 days, effective July 10, 2026. Updates take only a few seconds, and Neon prewarms your cache so performance isn't affected.

You can check for update notifications in your project's settings (Settings > Updates). On the Scale and Enterprise plans, you also receive an email notification in advance, in addition to the in-console notice. To learn more, see Updates.

Neon Community Corner

This week, we're spotlighting contributions and integrations from the Neon community and ecosystem.

Neon Testing now supports Bun Test

Neon Testing, the community-built integration testing library by Mikael Lirbank, shipped v3.0.0 with support for Bun Test alongside Vitest. Each test runs against its own isolated Neon branch, with DATABASE_URL set up and torn down automatically, so your tests hit the same schema and constraints as production without mocks or a shared local database.

npm install --save-dev neon-testing

View the package on npm and read the v3.0.0 release notes on GitHub.

Connect Neon to Gamut

Gamut, an AI agent hosting platform with native support for remote MCP servers, now connects to Neon through the Neon MCP server. Setup uses OAuth, matching the existing client flow. To get started, add Neon to your Gamut agent.

Docs & Postgres tutorial contributors

Our docs and Postgres tutorials get better thanks to fixes and improvements from the community. A quick thank you to contributors.

@AayushGoswami @AhmedYasinKUL @Arul-1911 @bcw117 @camro @chibx @codenim34 @crebelskydico @da-vaibhav @DorianDragaj @duffuniverse @fcdm @flow145 @harry-whorlow @houssaineamzil @ifeoluwak @Jaskaranrehal @jayhyp @karlhorky @keugenek @michaelgomeh @noo-dev @rahulrao0209 @Ranzeplay @realihorrud @rhutch117 @sanaeft @sdarnadeem @SefterM-zade @slotix @solisoares @this-fifo @VIM4L-M @webwurst

Original source

Neon CLI enhancements

We're continually improving the Neon CLI and the developer experience around it. Recent additions include branch-first dev loop (neon link, neon checkout, and neon env pull) commands and neon.ts. This week brings a shorter name plus two additional commands.

• The CLI is now just neon

You can now install the Neon CLI from npm as neon instead of neonctl: npm i -g neon (or run it with npx neon@latest). All commands are now documented as neon rather than neonctl. If you already use neonctl, nothing changes: it's the same CLI, neonctl still works as a command, and no migration or re-authentication is needed. See the Neon CLI install guide.

The latest CLI now requires Node.js 20.19.0 or higher (previously 18). An existing installation keeps working on your current Node.js version; if you're on an older version, upgrade Node.js before updating the CLI.

• Set up declarative branch management in one step

The new neon config init command scaffolds a starter neon.ts config file and installs the @neon/config and @neon/env packages, so you can define how each branch is set up (compute size, scale-to-zero, TTL, and which services it uses) declaratively, without any manual setup. It runs entirely locally, and neon link now offers to run it as its final step.

• Check your current branch instantly, with no network call

The new neon status command is a top-level alias for neon config status. Add --current-branch to print just the branch pinned in your local .neon file:

neon status --current-branch

Because it makes no network call, it's fast enough to run on every shell prompt. For example, add your current Neon branch to a starship prompt by appending this [custom.neon] module to ~/.config/starship.toml.

See the config command reference for more.

Neon Object Storage in the Files SDK

Neon Object Storage now has a first-class adapter in the Files SDK, the open-source library that gives you one upload, download, and presigned-URL API across S3, R2, GCS, and more. The neon adapter is wired up from the AWS_* variables Neon injects, so pointing your object storage backend at Neon is a one-line config change.

See the with-files-sdk example for a minimal script that uploads files to a branch-scoped bucket.

Neon Object Storage is part of Neon's new backend services, currently in private preview. If you haven't signed up yet, you can sign up and learn more.

Learn more about Lakebase Search

We recently opened Lakebase Search to all Neon users, adding scalable vector, keyword, and hybrid search to Postgres through the lakebase_vector and lakebase_text extensions. This week, our engineering team goes under the hood.

Read Lakebase Search: vector and BM25 on Neon blog post to learn why the usual pgvector + GIN setup breaks down at scale, and how lakebase_ann (IVF + RaBitQ) and lakebase_bm25 (Block-Max WAND) keep indexes on object storage so they stay ready across scale-to-zero and branching.

Update snapshot expiration anytime

You can now update a snapshot's expiration with the Update snapshot endpoint. Set expires_at to a future timestamp to change the retention deadline, or send null to remove it so the snapshot never expires. Previously, expiration could only be set when the snapshot was created.

Planned update notifications change

So that we can ship Neon improvements and fixes faster, the advance notice period for planned updates on the Scale and Enterprise plans is changing from 7 days to 3 days, effective July 10, 2026. Updates take only a few seconds, and Neon prewarms your cache so performance isn't affected.

You can check for update notifications in your project's settings (Settings > Updates). On the Scale and Enterprise plans, you also receive an email notification in advance, in addition to the in-console notice. To learn more, see Updates.

Neon Community Corner

This week, we're spotlighting contributions and integrations from the Neon community and ecosystem.

Neon Testing now supports Bun Test

Neon Testing, the community-built integration testing library by Mikael Lirbank, shipped v3.0.0 with support for Bun Test alongside Vitest. Each test runs against its own isolated Neon branch, with DATABASE_URL set up and torn down automatically, so your tests hit the same schema and constraints as production without mocks or a shared local database.

Connect Neon to Gamut

Gamut, an AI agent hosting platform with native support for remote MCP servers, now connects to Neon through the Neon MCP server. Setup uses OAuth, matching the existing client flow. To get started, add Neon to your Gamut agent.

Docs & Postgres tutorial contributors

Our docs and Postgres tutorials get better thanks to fixes and improvements from the community. A quick thank you to contributors.

Original source

The link command

The link command binds the current directory to a Neon project. It picks (or creates) an organization and project, resolves the project's default branch, and writes a .neon file with orgId, projectId, and branchId. Subsequent commands run in this directory (or any subdirectory) automatically pick up that context.

Requires neonctl 2.22.2 or later. Check your version with neonctl --version.

PREFER LINK OVER SET-CONTEXT

For most workflows, use neonctl link instead of manually running neonctl set-context --project-id .... The link command guides you through organization and project selection and ensures the context file is complete.

Usage

neonctl link [options]

Options

• --org-id: Organization ID to link to (string, not required)
• --project-id: Existing project ID to link to (string, not required)
• --project-name: Name for a new project to create and link to (string, not required)
• --region-id: Region ID for a new project (e.g. aws-us-east-2). Required with --project-name. (string, not required)
• --branch, --branch-id: Branch name or ID to pin in the context (resolved to its ID before writing). Without it, link only resolves the org and project — pin a branch with neonctl checkout (link never guesses a default). (string, not required)
• --params: JSON object with link parameters, e.g. '{"orgId":"...","projectId":"..."}' or '{"orgId":"...","projectName":"...","regionId":"..."}'. Flags take precedence over fields in --params. (string, not required)
• --agent: Emit a JSON state-machine response designed for AI agents instead of prompting. The output is a single JSON object with a discriminated status field describing the next step. (boolean, default false, not required)
• --yes, -y: Skip the "already linked" confirmation in interactive mode and re-link anyway. (boolean, default false, not required)
• --clear: Remove the org/project/branch context (writes an empty context file) instead of linking. (boolean, default false, not required)
• --checks: Verify the org/project/branch exist (and resolve the org from the project) before writing. On by default; use --no-checks to write the context offline with no API calls — it then requires --org-id and --project-id (--branch optional) and skips env pull. (boolean, default true, not required)
• --env-pull: Pull the linked branch's Neon env vars (DATABASE_URL, ...) into a local .env after linking. On by default; use --no-env-pull to skip, for example when injecting env at runtime with neon-env run (from @neondatabase/env) or neonctl dev. (boolean, default true, not required)

By default, linking pulls the linked branch's environment variables (such as DATABASE_URL) into a local .env file. Use --no-env-pull to skip this step, for example when you inject environment variables at runtime instead.

Interactive mode (default)

Run neonctl link with no flags for guided prompts:

Output example:

? Which organization would you like to link? › Personal Org (org-abc123)
? Which project would you like to link? › + Create new project
? Name for the new project: › my-app
? Which region should the new project run in? › AWS US East (Ohio) (aws-us-east-2)
Created project polished-snowflake-12345678 ("my-app") in aws-us-east-2.
Linked .neon:
orgId:     org-abc123
projectId: polished-snowflake-12345678
branchId:  br-steep-math-aiu3vve7

Non-interactive mode

Use flags or a --params JSON blob for scripts and CI:

# Link to an existing project
neonctl link --org-id org-abc123 --project-id polished-snowflake-12345678

# Create a new project and link
neonctl link --org-id org-abc123 --project-name my-app --region-id aws-us-east-2

# Same payload, one JSON blob
neonctl link --params '{"orgId":"org-abc123","projectName":"my-app","regionId":"aws-us-east-2"}'

Flags take precedence over fields in --params.

Agent mode

Use --agent for a JSON state machine designed for AI coding assistants. Each invocation returns a single JSON object with a status discriminator describing the next step, the available options, and the exact follow-up command to run.

Example response when an organization must be selected:

{
  "status": "needs_org",
  "instruction": "Ask the user which of these 2 organizations they want to link the current directory to. After they pick one, re-run the next_command_template with the chosen --org-id value.",
  "options": [
    {"id": "org-abc123", "name": "Personal Org"},
    {"id": "org-team", "name": "Team Org"}
  ],
  "next_command_template": "neonctl link --agent --org-id <org_id>"
}

When linking completes, the response includes status: "linked" with the context file path and project details.

Any unexpected failure in --agent mode is reported as JSON to stdout with exit code 1:

{
  "status": "error",
  "code": "CLIENT_ERROR",
  "message": "user has no access to projects"
}

The .neon context file

The link command is a thin wrapper around set-context: both write to the same .neon file, so anything link can write, set-context can write too.

link writes the file into the current working directory by default. If an existing .neon is found in any parent directory, that file is reused, so commands run from a subdirectory of a linked project still pick up the project's context. To pin the location explicitly, pass the global --context-file option.

Example .neon file:

{
  "orgId": "org-abc123",
  "projectId": "polished-snowflake-12345678",
  "branchId": "br-steep-math-aiu3vve7"
}

The first time a .neon file is created, the CLI adds .neon to .gitignore in that folder so local project settings are not committed by accident. If you want to commit .neon and share context with your team, remove the entry from .gitignore. The CLI doesn't re-add it when updating an existing file.

NOTE

Neon does not save confidential information to the context file (for example, auth tokens). You can safely commit this file to your repository or share it with others.

Organization-scoped API keys

Organization-scoped API keys (those created at the organization level rather than the user level) cannot list user organizations or call the regions endpoint. link handles this transparently:

• If the API key is org-scoped and at least one project already exists in the org, the CLI auto-detects the org_id from the first project.
• If the API key is org-scoped and no projects exist yet, --agent returns a needs_org response with options: [] and an instruction to find the org ID in the Neon Console. Interactive mode prints an error pointing to --org-id.
• When the regions endpoint is not allowed, link falls back to a built-in static region list.

Original source

Pin a branch in your local .neon context file

The checkout command pins a branch in the local context so subsequent commands target it. It's a focused helper over set-context for the common "switch the branch I'm working on" case. The checkout command requires neonctl 2.22.2 or later; check your version with neonctl --version.

checkout resolves the branch (by name or ID) against the project, then heals the .neon file: it always (re)writes projectId, branchId, and orgId (when the project has one), so a .neon that was missing fields or drifted ends up complete and consistent.

Usage

neonctl checkout [id | name] [options]

The branch argument is optional. Run neonctl checkout with no branch in an interactive terminal to fetch the project's branches and pick one from a list. In a non-interactive context (CI or no TTY), you must pass a branch explicitly.

Options

• --project-id: Project ID (string, not required)
• --env-pull: Pull the branch's Neon env vars (DATABASE_URL, ...) into a local .env after checkout. On by default; use --no-env-pull to skip, for example when injecting env at runtime with neon-env run (from @neondatabase/env) or neonctl dev. (boolean, default true, not required)

By default, checkout pulls environment variables into a .env file after checking out the branch; use --no-env-pull to skip this.

Branch ID vs name

Branch ID vs name is detected automatically (a br-… value is treated as an ID):

• ID: Matched strictly by ID. A non-existent ID is a hard "not found" error (IDs are server-assigned, so checkout never creates one).
• Name: Matched by name. If the name does not exist, in an interactive terminal checkout offers to create it (equivalent to neonctl branches create --name : branched from the project's default branch with a read-write compute), then checks it out. In a non-interactive context, a missing name is the usual "not found" error.

Project resolution

The project is resolved through the standard Neon CLI chain, each entry winning over the next:

1. --project-id flag
2. projectId from the closest .neon file (found by walking up from the current directory)
3. If still unresolved and the API key maps to exactly one project, that project is auto-detected (same behavior as branches and connection-string)

If none of those resolve a project, checkout prints an error explaining the chain above. In an interactive terminal it then offers to run neonctl link in the current folder so you can pick (or create) a project on the spot. In non-interactive contexts, it exits with a non-zero code instead of prompting.

Examples

Pin a branch by name. New Neon projects create a default branch named production:

neonctl checkout production --project-id polished-snowflake-12345678

Output:

INFO: Checked out branch br-steep-math-aiu3vve7 on project polished-snowflake-12345678. Updated /path/to/cwd/.neon.

The updated .neon file:

{
  "orgId": "org-abc123",
  "projectId": "polished-snowflake-12345678",
  "branchId": "br-steep-math-aiu3vve7"
}

Pick a branch interactively (requires a linked project or --project-id):

neonctl checkout

Pin a branch by ID:

neonctl checkout br-cool-snow-12345678 --project-id polished-snowflake-12345678

After checking out a branch, commands such as connection-string and psql use the pinned branch by default.

Original source

Connect to a Neon database via psql

The psql command connects to a database in your Neon project using the psql client. It builds a connection string for the specified branch (or the default branch from your context file) and launches psql, equivalent to running neonctl connection-string --psql as a dedicated top-level command. Requires neonctl 2.22.2 or later. Check your version with neonctl --version. If --project-id is omitted, the CLI resolves it from your context file, auto-selects when your account has only one project, and prompts otherwise. --role-name and --database-name are needed only when the branch has more than one role or database.

Usage

neonctl psql [branch] [options] [-- psql-args]

The [branch] is the branch name or ID. If omitted, the default branch from your context (or the project's default branch) is used. You can also use the point-in-time format branch@timestamp or branch@lsn for time travel connections. Arguments after -- are forwarded to psql.

Options

Option Description Type Default Required --project-id Project ID string — No --role-name Role name string — No --database-name Database name string — No --pooled Use pooled connection boolean false No --endpoint-type Endpoint type string — No --ssl SSL mode Possible values: require, verify-ca, verify-full, omit string require No

neonctl psql uses the native psql binary from your $PATH if one is available, and otherwise falls back to a built-in TypeScript implementation, so no PostgreSQL client tools installation is required. The built-in implementation is a full port, not a simplified subset: it supports SCRAM-SHA-256 authentication, backslash commands (\d, \dt, \d+, etc.), tab completion, command history, and COPY. It's verified against Postgres 14 through 18.

To force the built-in implementation in CI or other environments where native psql is present but you want consistent behavior, set NEONCTL_PSQL_FALLBACK=1.

Examples

Connect to the default branch:

neonctl psql

Connect to a named branch. New Neon projects create a default branch named production:

neonctl psql production

Run a single query:

neonctl psql production -- -c "SELECT version()"

Run an SQL file:

neonctl psql production -- -f dump.sql

Connect to a branch at a specific point in time:

neonctl psql production@2024-01-01T00:00:00Z

Use a pooled connection:

neonctl psql --pooled

Original source

Provision and manage the Neon Data API from the CLI

The data-api command provisions and manages the Neon Data API for a database. For Console-based management, see Manage Data API.

Requires neonctl 2.22.2 or later. Check your version with neonctl --version.

Subcommands: create, get, update, refresh-schema, delete.

If --project-id, --branch, or --database are omitted, the CLI resolves them from your context file, auto-selects when there is only one option, and prompts otherwise.

Settings flags

The create and update subcommands share a set of settings flags that configure how the Data API serves your database:

• --db-aggregates-enabled: Enable aggregate functions in queries (boolean)
• --db-anon-role: Database role used for anonymous (unauthenticated) requests (string)
• --db-extra-search-path: Extra schemas appended to the search path (string)
• --db-max-rows: Maximum number of rows returned by a single request (number)
• --db-schemas: Comma-separated list of schemas exposed via the Data API (string)
• --jwt-role-claim-key: JWT claim path used to extract the role (string)
• --jwt-cache-max-lifetime: Maximum JWT cache lifetime in seconds (number)
• --openapi-mode: OpenAPI mode. Choices: ignore-privileges, disabled (string)
• --server-cors-allowed-origins: CORS allowed origins (string)
• --server-timing-enabled: Enable Server-Timing response headers (boolean)

neonctl data-api create

Provisions the Neon Data API for a database.

Usage:

neonctl data-api create [options]

Options include:

• --auth-provider: Authentication provider Possible values: neon_auth, external (string)
• --jwks-url: URL that lists the JWKS (used with external auth) (string)
• --provider-name: Name of the auth provider (e.g. Clerk, Stytch, Auth0) (string)
• --jwt-audience: Expected JWT audience claim (string)
• --add-default-grants: Grant all permissions on tables in the public schema to authenticated users (boolean)
• --skip-auth-schema: Skip creating the auth schema and RLS functions (boolean)
• ... plus the settings flags listed above.

Example:

neonctl data-api create --database neondb --auth-provider neon_auth

neonctl data-api get

Shows the Neon Data API status and settings.

Usage:

neonctl data-api get [options]

Options:

• --project-id: Project ID (string)
• --branch: Branch ID or name (string)
• --database: Database name (string)

Example:

neonctl data-api get --database neondb

neonctl data-api update

Updates Neon Data API settings. By default, the flags you provide are merged with the current settings. Pass --replace to overwrite all settings with only the flags you provide.

Usage:

neonctl data-api update [options]

Options include:

• --replace: Replace settings with only the flags provided. Omitted settings revert to server defaults. (boolean, default false)
• ... plus the settings flags listed above.

Example:

neonctl data-api update --database neondb --db-max-rows 1000

neonctl data-api refresh-schema

Refreshes the Data API schema cache without changing settings.

Usage:

neonctl data-api refresh-schema [options]

Options:

• --project-id: Project ID (string)
• --branch: Branch ID or name (string)
• --database: Database name (string)

Example:

neonctl data-api refresh-schema --database neondb

neonctl data-api delete

Deletes the Neon Data API for a database.

Usage:

neonctl data-api delete [options]

Options:

• --project-id: Project ID (string)
• --branch: Branch ID or name (string)
• --database: Database name (string)

Example:

neonctl data-api delete --database neondb

Original source

Set default project context for CLI sessions to avoid repeating project ID

The set-context command sets a background context for your CLI sessions, so you don't have to specify the project ID in every command. The context is saved to a default .neon file in the current directory, or to a named context file of your choice, and stays in place until you reset it or remove the file.

PREFER LINK OR CHECKOUT

For most workflows, use neonctl link to bind a directory to a project or neonctl checkout to switch branches. Use set-context when you need to set context values directly (for example, in scripts).

HOW THE CLI FINDS YOUR .NEON FILE

When you run a command, the CLI starts in your current directory and checks for a .neon file. If it does not find one, it checks the parent directory, then the parent of that, and so on until it finds a .neon file or reaches your home directory. This means you can run commands from any subdirectory of a linked project without re-specifying --project-id.

To write context to a specific file or location, use --context-file.

Usage

neonctl set-context [options]

To save the context to a file other than the default .neon file, add the global --context-file option. You can switch contexts by providing different files.

Options

Option Description Type Default Required
--project-id Project ID string — No
--org-id Organization ID string — No
--branch-id Branch ID string — No

Set at least one of these options.

Using the default context file

Set the context to the default .neon file:

neonctl set-context --project-id patient-frost-50125040 --org-id org-bright-sky-12345678

List all branches for this project with branches list, without including --project-id or --org-id, even if you belong to multiple organizations or have multiple projects:

neonctl branches list

Output example:

┌──────────────────────────┬─────────────┬─────────┬──────────────────────┬──────────────────────┐
│ Id                       │ Name        │ Default │ Created At           │ Updated At           │
├──────────────────────────┼─────────────┼─────────┼──────────────────────┼──────────────────────┤
│ br-raspy-meadow-26349337 │ development │ false   │ 2023-11-28T19:19:11Z │ 2023-12-01T00:18:21Z │
├──────────────────────────┼─────────────┼─────────┼──────────────────────┼──────────────────────┤
│ br-curly-bar-82389180    │ main        │ true    │ 2023-10-23T12:49:41Z │ 2023-12-01T00:18:21Z │
└──────────────────────────┴─────────────┴─────────┴──────────────────────┴──────────────────────┘

Using a named context file

Set the context to the context file of your choice:

neonctl set-context --project-id plain-waterfall-84865553 --context-file Documents/MyContext

List all branches with branches list. The context file provides the project:

neonctl branches list --context-file Documents/MyContext

Output example:

┌─────────────────────────────┬─────────────┬─────────┬──────────────────────┬──────────────────────┐
│ Id                          │ Name        │ Default │ Created At           │ Updated At           │
├─────────────────────────────┼─────────────┼─────────┼──────────────────────┼──────────────────────┤
│ br-soft-base-86343042       │ development │ false   │ 2023-11-21T18:41:47Z │ 2023-12-01T00:00:14Z │
├─────────────────────────────┼─────────────┼─────────┼──────────────────────┼──────────────────────┤
│ br-young-bush-89857627      │ main        │ true    │ 2023-11-21T18:00:10Z │ 2023-12-01T03:33:53Z │
├─────────────────────────────┼─────────────┼─────────┼──────────────────────┼──────────────────────┤
│ br-billowing-union-41102466 │ staging     │ false   │ 2023-11-21T18:44:22Z │ 2023-12-01T08:32:40Z │
└─────────────────────────────┴─────────────┴─────────┴──────────────────────┴──────────────────────┘

NOTE

These two branches list commands use independent contexts in the same account: the default .neon file points to patient-frost-50125040, while the named context file points to plain-waterfall-84865553. You can set as many context files as you'd like, using unique names or different directories.

Setting context when creating a new project

Use --set-context to set the project context at creation time:

neonctl projects create --name MyLatest --set-context

This creates a hidden .neon file by default with the following context:

{
  "projectId": "quiet-water-76237589"
}

Commands that would normally require --project-id now default to this context.

Reset or remove context

To clear the current context, either:

1. Run the set-context command with no options:

   neonctl set-context

2. Delete the .neon file (or your custom --context-file):

   rm .neon

   Or for a custom context file:

   rm your_context_file

.gitignore on first create

The first time a .neon file is created in a directory, the CLI adds .neon to .gitignore in that same folder:

• If no .gitignore exists, the CLI creates one with a single .neon line.
• If .gitignore already exists, the CLI appends .neon only if it is not already listed.

This keeps local project settings out of git by default. If you want to commit .neon and share context with your team, remove the entry from .gitignore. The CLI will not re-add it when updating an existing .neon file.

NOTE

Neon does not save any confidential information to the context file (for example, auth tokens). You can safely commit this file to your repository or share with others.

Original source

The Neon command-line interface: every command, with options and examples

One CLI for every Neon surface: manage Postgres, Functions, Storage, the Data API, and Neon Auth from the terminal, with branch-scoped workflows built in.

Install

npm i -g neonctl

Commands Link to Commands

Commands

neonctl — commands

setup & context

auth Browser OAuth; stores credentials locally.
Full reference ↗
$ neonctl auth

me Show the authenticated user.
Full reference ↗
$ neonctl me

set-context Write org/project/branch context to .neon.
Full reference ↗
OPTIONS

• --project-id
• --org-id
• --branch-id

$ neonctl set-context --project-id polished-snowflake-1234

checkout Pin a branch in .neon; auto-pulls its env vars.
Full reference ↗
OPTIONS

• --project-id
• --env-pull

$ neonctl checkout feat/auth

link Bind the directory to a project; writes .neon and pulls env.
Full reference ↗
OPTIONS

• --org-id
• --project-id
• --project-name
• --region-id
• --branch
• --params
• --agent
• --yes
• --clear
• --checks
• --env-pull

$ neonctl link
$ neonctl link --org-id org-abc --project-id polished-snowflake-1234

init Wire up MCP, agent skills, and editor (Cursor/VS Code/Claude).
Full reference ↗
OPTIONS

• --preview
• --skip-migrations
• --data
• --agent

$ npx neonctl@latest init

env Write the branch's DATABASE_URL + Neon vars to .env.
Full reference ↗
SUBCOMMANDS

• pull

$ neonctl env pull

bootstrap Scaffold a new project from a Neon starter template
Full reference ↗
OPTIONS

• --template
• --list-templates
• --force
• --agent
• --default
• --install
• --git
• --link

$ neonctl bootstrap my-app
$ neonctl bootstrap . --template hono
$ neonctl bootstrap my-app --default

projects & branches

projects Manage projects.
Full reference ↗
SUBCOMMANDS

• list
• create
• update
• delete
• recover
• get

$ neonctl projects list

branches Create, diff, reset, restore, and manage branches.
Full reference ↗
SUBCOMMANDS

• list
• create
• reset
• restore
• rename
• set-default
• set-expiration
• add-compute
• delete
• get
• schema-diff

$ neonctl branches create --name feat/auth --parent main
$ neonctl branches restore main ^self@2024-05-06T10:00:00Z --preserve-under-name backup
$ neonctl branches schema-diff production development

databases Manage databases on a branch.
Full reference ↗
SUBCOMMANDS

• list
• create
• delete

$ neonctl databases create --name analytics

roles Manage Postgres roles.
Full reference ↗
SUBCOMMANDS

• list
• create
• delete

$ neonctl roles create --name app_user

operations Inspect async operations.
Full reference ↗
SUBCOMMANDS

• list

$ neonctl operations list

connect to postgres

connection-string Print a connection URI for a branch/role/db.
Full reference ↗
OPTIONS

• --project-id
• --role-name
• --database-name
• --pooled
• --prisma
• --endpoint-type
• --extended
• --psql
• --ssl

$ neonctl connection-string main
$ neonctl connection-string main --pooled --prisma

psql Open a SQL session (embedded psql fallback built in).
Full reference ↗
OPTIONS

• --project-id
• --role-name
• --database-name
• --pooled
• --endpoint-type
• --ssl

$ neonctl psql main -- -c "SELECT 1"

config as code

dev Run Neon Functions locally with hot reload + branch env.
Full reference ↗
OPTIONS

• --source
• --port

$ neonctl dev

config Drive a branch from a neon.ts policy.
Full reference ↗
SUBCOMMANDS

• status
• plan
• apply

$ neonctl config apply

deploy Alias for config apply; reconciles the policy.
Full reference ↗
OPTIONS

• --project-id
• --branch
• --config
• --env
• --update-existing
• --allow-protected
• --env-pull

$ neonctl deploy

functions, storage & data

data-api Manage the Neon Data API for a database.
Full reference ↗
SUBCOMMANDS

• create
• get
• update
• refresh-schema
• delete

$ neonctl data-api create

neon-auth Manage Neon Auth on a branch.
Full reference ↗
SUBCOMMANDS

• enable
• status
• disable
• oauth-provider
• domain
• config
• plugins
• user

$ neonctl neon-auth enable

bucket Branch-scoped object storage and its objects.
Full reference ↗
SUBCOMMANDS

• create
• list
• delete
• object

$ neonctl bucket create my-assets

functions Deploy and manage Neon Functions on a branch.
Full reference ↗
SUBCOMMANDS

• deploy
• list
• get
• delete

$ neonctl functions deploy api --src ./api.ts

org & network

ip-allow Manage the project IP allowlist.
Full reference ↗
SUBCOMMANDS

• list
• add
• remove
• reset

$ neonctl ip-allow add 203.0.113.0/24

vpc Manage VPC endpoints and project restrictions.
Full reference ↗
SUBCOMMANDS

• endpoint
• project

$ neonctl vpc endpoint list

orgs List organizations you belong to.
Full reference ↗
SUBCOMMANDS

• list

$ neonctl orgs list

Agent mode

Every command supports --output json for machine-readable results, and setting the NEON_API_KEY environment variable authenticates non-interactively. For AI agents, neonctl link --agent emits a JSON state-machine response with a discriminated status field describing the next step, instead of prompting.

Global options

Global options are optional and work with any Neon CLI command.

More about global options:

• Output: table output may omit fields. Use --output json or --output yaml to see all data.
• Authentication: the CLI checks credentials in this order: the --api-key option, the NEON_API_KEY environment variable (export NEON_API_KEY=), the credentials.json file that neonctl auth creates in the config directory (override its location with --config-dir), then interactive web authentication. To get a key, see Create an API key.
• Context file: sets a default organization, project, or branch so you don't repeat IDs in every command. Create one with neonctl link (preferred) or set-context.
• Analytics: Neon collects anonymous data about which commands and options are used, never user-defined data such as project IDs or command payloads. Opt out with --no-analytics.
• Help: --help works at every level: neonctl --help, neonctl branches --help, neonctl branches create --help.

GitHub repository

The Neon CLI is open source. See the neondatabase/neon-pkgs repository.

Original source

Agent skills for Neon Object Storage, Functions, and AI Gateway

Neon Agent Skills are instruction files that teach AI coding assistants how to work with Neon. The collection now includes skills for Neon Functions, Object Storage, and AI Gateway, the backend services currently in private preview.

To install all Neon agent skills:

npx skills add neondatabase/agent-skills

For the complete list of skills and other install options, see the Agent Skills documentation.

Lakebase Search is now available to all users

Lakebase Search is now available to all Neon users on Postgres 16+. Two extensions, lakebase_vector and lakebase_text, bring vector, keyword, and hybrid search into Postgres, so you can run semantic RAG, exact-term lookups, and combined rankings without a separate search stack.

First, enable the shared preload libraries and restart your compute. Then install the extensions and query with the same operators you already know from pgvector and full-text search:

CREATE EXTENSION IF NOT EXISTS lakebase_vector CASCADE;
CREATE EXTENSION IF NOT EXISTS lakebase_text CASCADE;
-- Semantic: nearest neighbors by embedding
SELECT title FROM documents ORDER BY embedding <=> $query_vector LIMIT 5;
-- Keyword: BM25 relevance with top-K pushdown
SELECT title FROM documents ORDER BY body_tsv <@ to_bm25query(to_tsvector('english', 'vector search'), 'documents_bm25') LIMIT 5;

For production search, combine both with Reciprocal Rank Fusion (RRF): merge top vector and BM25 candidates into one score. The get started guide includes a full hybrid example in TypeScript.

Why Lakebase Search on Neon:

• lakebase_ann: drop-in pgvector compatibility; scales to 1B+ vectors; index builds 50-100× faster than HNSW
• lakebase_bm25: standard tsvector types; BM25 ranking GIN can't do natively
• Scale-to-zero: indexes live in storage, so they're ready immediately after a cold start; branches copy indexes without rebuilds

See the Lakebase Search overview to get started.

Postgres version updates

We updated supported Postgres versions to 14.23, 15.18, 16.14, 17.10, and 18.4, respectively.

When a new minor version is available on Neon, it is applied the next time your compute restarts. For more about how we handle Postgres version upgrades, refer to our Postgres version support policy.

Ephemeral database branches for Vercel Eve agent sessions

In June, Vercel introduced Eve, an open-source, filesystem-first framework for durable agents. Sessions checkpoint as they run, can last for days, and pause for human approval before resuming. Eve includes a sandbox, evals, and built-in channels.

We published a guide that pairs Eve with Neon branching. The integration is a small hook in agent/hooks/provision-branch.ts: create a branch when a session starts, delete it when the session ends. Agent tools read the branch connection URI and work against an isolated copy of your production schema.

Read the guide: Running Vercel Eve agents and evals on disposable Neon branches

Original source

Agent skills for Neon Storage, Functions, and AI Gateway

Agent skills for Neon Storage, Functions, and AI Gateway are instruction files that teach AI coding assistants how to work with Neon. The collection now includes skills for Neon Functions, Object Storage, and AI Gateway, the backend services currently in private preview.

If you haven't requested preview access yet, sign up below and we'll send you the private preview guide to get started.

Get early access to the Neon backend platform

We're expanding Neon into a complete backend platform. Drop your email and we'll reach out soon for early access.

To install all Neon agent skills:

npx skills add neondatabase/agent-skills

For the complete list of skills and other install options, see the Agent Skills documentation.

Lakebase Search is now available to all users

Lakebase Search is now available to all Neon users on Postgres 16+. Two extensions, lakebase_vector and lakebase_text, bring vector, keyword, and hybrid search into Postgres, so you can run semantic RAG, exact-term lookups, and combined rankings without a separate search stack.

First, enable the shared preload libraries and restart your compute. Then install the extensions and query with the same operators you already know from pgvector and full-text search:

CREATE EXTENSION IF NOT EXISTS lakebase_vector CASCADE;
CREATE EXTENSION IF NOT EXISTS lakebase_text CASCADE;
-- Semantic: nearest neighbors by embedding
SELECT title FROM documents ORDER BY embedding <=> $query_vector LIMIT 5;
-- Keyword: BM25 relevance with top-K pushdown
SELECT title FROM documents ORDER BY body_tsv <@ to_bm25query(to_tsvector('english', 'vector search'), 'documents_bm25') LIMIT 5;

For production search, combine both with Reciprocal Rank Fusion (RRF): merge top vector and BM25 candidates into one score. The get started guide includes a full hybrid example in TypeScript.

Why Lakebase Search on Neon:

• lakebase_ann: drop-in pgvector compatibility; scales to 1B+ vectors; index builds 50-100× faster than HNSW
• lakebase_bm25: standard tsvector types; BM25 ranking GIN can't do natively
• Scale-to-zero: indexes live in storage, so they're ready immediately after a cold start; branches copy indexes without rebuilds

See the Lakebase Search overview to get started.

Postgres version updates

We updated supported Postgres versions to 14.23, 15.18, 16.14, 17.10, and 18.4, respectively.

When a new minor version is available on Neon, it is applied the next time your compute restarts. For more about how we handle Postgres version upgrades, refer to our Postgres version support policy.

Ephemeral database branches for Vercel Eve agent sessions

In June, Vercel introduced Eve, an open-source, filesystem-first framework for durable agents. Sessions checkpoint as they run, can last for days, and pause for human approval before resuming. Eve includes a sandbox, evals, and built-in channels.

We published a guide that pairs Eve with Neon branching. The integration is a small hook in agent/hooks/provision-branch.ts: create a branch when a session starts, delete it when the session ends. Agent tools read the branch connection URI and work against an isolated copy of your production schema.

export default defineHook({
  events: {
    async "session.started"(_event, ctx) {
      const branch = await createBranch(`eve-${ctx.session.id.slice(0, 12)}`);
      dbBranch.update(() => ({ connectionUri: branch.connectionUri }));
    },
  },
});

Read the guide: Running Vercel Eve agents and evals on disposable Neon branches

Original source