Changelog

Faster writes on Neon

Neon now delivers significantly faster writes across all projects. For write-heavy workloads, this optimization delivers up to a 5x performance improvement in our testing.

This performance enhancement comes from reducing extra write overhead in Postgres and moving more of that work to Neon's storage layer, while preserving durability.

For a technical deep dive, see the blog post: Everyone gets faster writes: Turning off FPW on Neon.

Snapshot billing

Snapshot storage pricing took effect on May 1, 2026. Snapshots are now billed at $0.09/GB-month. This applies to both manual snapshots and snapshots created by automated backup schedules.

To review snapshot billing, visit the Billing page in the Neon Console. To view snapshot storage, see the Backup & Restore page.

For more about snapshots, see Backup & restore.

Require two-factor authentication for your organization

Organization admins can now require two-factor authentication for everyone in the organization. You can only enable this if your own account already uses 2FA, so you don't lock yourself out while rolling out the policy. Turn this feature on in Organization → Settings.

For details, see Require 2FA for organization members.

Fixes & improvements

Postgres 18 is generally available

Postgres 18 is now generally available on Neon. The preview limitations have been lifted, and Postgres 18 is fully supported for production workloads. To get started, create a new project and select 18 as the Postgres version.

To learn more about the new features and improvements in Postgres 18:

• Read our blog post: Postgres 18 Is Out: Try it on Neon
• Review the official Postgres 18 release notes

For Neon's Postgres version support policy, see Postgres version support.

Manage organization spending limits via the API

Last week we introduced organization spending limits in the Neon Console. From the Billing page, org admins can set a monthly cap, and Neon emails admins when spend reaches 80% and 100% of that limit.

This week the same functionality is available through the Neon API so you can manage your spend limit programmatically.

• View monthly spend limit

  curl "https://console.neon.tech/api/v2/organizations/${ORG_ID}/billing/spending_limit" \
    -H "Authorization: Bearer ${NEON_API_KEY}" \
    -H "Accept: application/json"

• Set monthly spend limit

  curl -X PUT "https://console.neon.tech/api/v2/organizations/${ORG_ID}/billing/spending_limit" \
    -H "Authorization: Bearer ${NEON_API_KEY}" \
    -H "Content-Type: application/json" \
    -d '{"spending_limit_cents":10000}'

• Delete monthly spend limit

  curl -X DELETE "https://console.neon.tech/api/v2/organizations/${ORG_ID}/billing/spending_limit" \
    -H "Authorization: Bearer ${NEON_API_KEY}" \
    -H "Accept: application/json"

For details, see Spending limits and the April 24 changelog.

New NAT gateway IPs and VPC endpoint services in US East (N. Virginia)

We've expanded infrastructure capacity in the AWS US East (N. Virginia) region (us-east-1) with new NAT gateway IP addresses and new VPC endpoint service addresses for Private Networking.

If you use Private Networking in us-east-1, 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.

Load test at Grafana k6 and Neon branches

Neon branching gives you an isolated copy of your database with production-like data and separate compute, so you can run Grafana k6 against your application without hammering production or relying on an undersized staging database. Create a branch from your production branch, point your app at the branch connection string, exercise realistic concurrency with k6, then tune queries and indexes on the branch and validate improvements before you ship changes.

The guide Simulate production load using Neon branching and k6 walks through the full flow. It uses a branch named load-test-branch in the examples; with the Neon CLI, a minimal create from your real data branch looks like this:

neon branches create \
  --name load-test-branch \
  --parent main \
  --project-id "$NEON_PROJECT_ID"

Use the new branch’s connection URI in DATABASE_URL, then run your app and k6 against that database.

The guide’s load-test.js centers on options: stages ramp virtual users up and down, and thresholds fail the run if latency or errors cross the line. A tiny export default is still required so k6 knows what each virtual user does. The full guide adds category mix, check, and sleep for realism:

const http = require('k6/http');

export const options = {
  stages: [
    { duration: '10s', target: 20 },
    { duration: '30s', target: 50 },
    { duration: '10s', target: 0 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<50'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  http.get('http://localhost:3000/api/products?category=Electronics');
}

Organization spend limits and email alerts

You can now set a monthly spending limit for your organization from the Billing page in the Neon Console. When spend reaches 80% and 100% of that limit, Neon sends email alerts to organization admins. Spend is evaluated about every 15 minutes, and reminder emails continue weekly until you raise the limit or the billing cycle resets.

When you enable a limit, you enter a dollar amount and choose threshold behavior. Email alerts are available now. In a future release, you'll be able to suspend computes automatically when the limit is reached.

To get started, see Spending limits.

Monitor snapshot storage consumption

Building on the recent snapshot size fields added to snapshot API responses, the Retrieve project consumption metrics endpoint now supports a snapshot_storage_bytes_month metrics parameter. Use it to track monthly snapshot storage in your project-level consumption reporting.

Example response body (excerpt):

{
  "timeframe_start": "2026-02-05T00:00:00Z",
  "timeframe_end": "2026-02-06T00:00:00Z",
  "metrics": [
    { "metric_name": "root_branch_bytes_month", "value": 758611968 },
    { "metric_name": "instant_restore_bytes_month", "value": 983488 },
    { "metric_name": "snapshot_storage_bytes_month", "value": 0 }
  ]
}

For the full list of metrics, see Querying consumption metrics.

One-click Neon MCP setup for Kiro

The Neon MCP Server now supports an Add to Kiro badge for one-click MCP setup. Thanks to Anil Maktala for the contribution.

Build durable agents with Pydantic AI, DBOS, and Neon

Multi-step agents depend on LLMs and tools that can time out, rate limit, or fail mid-run. A practical pattern is durable execution: checkpoint progress in Postgres so a workflow can resume after a crash or retry without redoing expensive steps from scratch. DBOS provides that durable execution layer, Pydantic AI structures agent logic and tool orchestration, and Neon backs the database so checkpoint state lives in serverless Postgres that scales with your workload.

For a full walkthrough with a working example, see Building Durable AI Agents with Pydantic AI, DBOS, and Neon.

Making Neon docs work for AI agents

We've been optimizing our docs for AI agents. The post Agents grew up, so did our docs covers what worked, what didn't, and what we're still figuring out. It includes findings from a scan of 250+ doc sites, plus details like our MDX-to-Markdown pipeline, content negotiation (serving Markdown to agents or by appending .md to any doc URL), agent-aware 404 handling, and a restructured llms.txt index.