Changelog

New connection limits for autoscaling users

In Postgres, the max_connections setting determines the maximum number of concurrent client connections the database server can handle. In Neon, this setting is automatically adjusted based on your compute size. With Neon's autoscaling feature, max_connections is now determined by your maximum compute size instead of your minimum compute size.

This update significantly increases connection limits. For example, the following compute sizes support these connection limits:

• 2 CU = 901 max connections
• 8 CU = 3604 max connections

Previously, a 2 CU ↔ 8 CU autoscaling configuration was capped at 901 connections. Now, the same configuration supports up to 3604 connections.

Higher PgBouncer default_pool_size setting

Neon supports connection pooling using PgBouncer. In Neon's PgBouncer configuration, the default_pool_size setting was previously set to 64, regardless of your compute size. This meant that the number of POstgres connections was limited to 64 per user/database pair. This setting is now defined as default_pool_size=0.9 * max_connections, significantly increasing the maximum number of concurrent Postgres connections. For example, on an 8 CU compute with a max_connections limit of 3604, the default_pool_size setting increases from 64 to 3243 (0.9 * 3604).

Neon is now available on AgentStack

Neon is now available as tool for agents written using the AgentStack framework. The Neon tool allow agents to instantly create ephemeral or long-lived Postgres instances for storing structured data. You can explore the implementation of Neon tool in the neon_tool.py template file in the AgentStack repo.

Neon is now available on Composio

Neon is now available as a tool on Composio, letting you integrate Neon with LLMs & AI agents via function calls to Neon's API.

Neon Auth.js adapter

We've recently introduced an Auth.js adapter for Neon, which enables storing user and session data in your Neon database. For adapter installation and setup instructions, see Neon Adapter in the Auth.js docs.

New default Postgres version

Postgres 17 is now the default for newly created Neon projects. Neon continues to support Postgres 14, 15, and 16.

Fixes & improvements

• Drizzle Studio update

  The Drizzle Studio integration that powers the Tables page in the Neon Console has been updated. For the latest improvements and fixes, see the Neon Drizzle Studio Integration Changelog.

• Console updates

  Adjusted billing period start dates in the console to align with the beginning of the current month. Previously, timezone differences could cause the start date to display as the last day of the previous month.

• Virtual Private Networking

  Fixed an issue where invalid VPC endpoint IDs would not be deleted. Invalid endpoint IDs are now transitioned to a deleted state after 24 hours and automatically removed at a later date.

• Neon API

• The List branches endpoint now supports sorting and pagination with the addition of sort_by, sort_order, limit, and cursor query parameters. The sorted by options include updated_at, created_at, or name, and sort_order options include asc and desc. After an initial call, pagination support lets you list the next or previous number of branches specified by the limit parameter.

• Added a new List running operations endpoint, which retrieves a list of all running operations for the specified Neon project.

• Neon API Client

  The TypeScript SDK for the Neon API was updated to a new version (1.11.4). The new version adds support for creating organization API keys.

• Neon CLI

  For the latest Neon CLI updates, you can always refer to the Neon CLI release page.

• Logical Replication

  Before dropping a database, Neon now drops any logical replication subscriptions defined in the database.

• Fixes

  • Fixed an issue that permitted installing the Neon GitHub integration for organizations or personal accounts where the integration was already installed.