Updates

To keep your Neon computes and Postgres instances up to date with the latest patches and features, Neon applies updates to your project's computes. We notify you of updates in advance so that you can plan for them if necessary. On Neon's paid plans, you can select an update window (a specific day and hour for updates).

How Neon applies updates

To apply updates to your compute (Postgres upgrades, security patches, and similar changes), Neon restarts the compute where Postgres runs. On paid plans, this happens within the update window you choose. On the Free plan, Neon schedules updates for you. The restart itself typically takes only a few seconds.

To protect performance, Neon prewarms your compute's cache during the update process, without adding time to the restart. Prewarming means repopulating Postgres's in-memory buffer cache from storage before your workload continues, so frequently used data is already in memory instead of being read cold from storage after the restart. Prewarming runs automatically. You do not configure it. There are no additional compute or storage costs associated with this behavior.

For technical details, see Zero-Downtime Patching Part 1: Prewarming.

What updates are included?

Updates to Neon computes may include some or all of the following:

• Postgres minor version upgrades, typically released quarterly
• Security patches and updates
• Operating system updates
• Neon features and enhancements
• Updates to other tools and components included in Neon compute images

Neon compute updates do not include Neon platform maintenance.

How often are updates applied?

Updates are typically released weekly but may occur more or less frequently, as needed.

Neon applies updates to computes based on the following rules:

• Computes that have been active for 30 days or more receive updates.
• Computes that are restarted receive available updates immediately.
• Computes in a transition state (for example, shutting down or restarting) at the time of an update are not updated.
• Computes whose maximum autoscale size is greater than 8 CU are not updated automatically. If your maximum is exactly 8 CU, your compute is not treated as a large compute and receives scheduled updates like smaller sizes. See Updating large computes.

If a compute is excluded from an update, Neon will apply the missed update with the next update, assuming the compute meets the update criteria mentioned above.

Updates on the Free plan

On the Free plan, updates are scheduled and applied automatically. You can check your project's settings for updates. We'll post a notice there at least 1 day ahead of a planned update, letting you know when it's coming.

To view planned updates:

1. Go to the Neon project dashboard.

2. Select Settings > Updates.

   

If you want to apply an update ahead of the scheduled date, see Applying updates ahead of schedule.

Updates on paid plans

On Neon's paid plans, you can set a preferred update window by specifying the day and hour. Updates will be applied within this window, letting you plan for the required compute restart.

You can specify an update window in your Neon project's settings or using the Neon API.

Check for updates using the Neon API

You can retrieve your update window and check for planned updates using the Retrieve project details endpoint.

To get your project details, send the following request, replacing <your_project_id> with your Neon project ID, and $NEON_API_KEY with your Neon API key:

curl --request GET \
     --url https://console.neon.tech/api/v2/projects/<your_project_id> \
     --header 'accept: application/json' \
     --header 'authorization: Bearer $NEON_API_KEY'

In the response, locate the maintenance_window field. It specifies the selected weekday and hour for updates. For Free plan accounts, the update window is set by Neon. Paid plan accounts can choose a preferred update window. The weekdays value is a number from 1 to 7, representing the day of the week.

{
...
  "settings": {
      "maintenance_window": {
         "weekdays": [5],
         "start_time": "07:00",
         "end_time": "08:00"
      },
   }
  "maintenance_scheduled_for": "2025-02-07T07:00"
...
}

If there's a planned update, you'll also find a maintenance_scheduled_for field in the response body. This value matches the start_time in your maintenance_window but is formatted as a timestamp. If the maintenance_scheduled_for field in not present in the response, this means there is no planned update at this time.

Applying updates ahead of schedule

Computes receive available updates immediately upon restart. For example, if Neon notifies you about an upcoming update, you can apply it right away by restarting the compute. However, the notification won't be cleared in this case. When the planned update time arrives, no further action will be taken since the compute is already updated.

If a compute regularly scales to zero, it will receive updates when it starts up again. In such cases, you may not need to pay much attention to update notifications, as updates will be applied naturally through your compute's stop/start cycles.

For compute restart instructions, see Restart a compute.

Updating large computes

Computes whose maximum autoscale size is greater than 8 CU are not updated automatically (scheduled updates do not apply). Computes capped at exactly 8 CU follow the usual automatic update rules above. To apply updates on a large compute, you'll need to restart it manually. A restart may occur automatically due to scale to zero, but if scale to zero is disabled or your compute runs continuously, please plan for manual restarts.

Neon typically releases compute updates weekly, so we recommend scheduling weekly compute restarts.

For restart instructions, see Restart a compute.

Handling connection disruptions during compute updates

Prewarming helps keep the cache warm through the update, so query performance is not affected by a cold cache, but you may still experience a brief connection drop due to the compute restart.

Most Postgres connection drivers include built-in retry mechanisms that automatically handle short-lived connection interruptions. This means that for most applications, a brief restart should result in minimal disruption, as the driver will reconnect automatically.

However, if your application has strict availability requirements, you may want to ensure that your connection settings are configured to allow for retries. Check your driver's documentation for options like connection timeouts, retry intervals, and connection pooling strategies. Your configuration should account for the few seconds it takes to apply updates to your Neon compute. For related information, see Build connection timeout handling into your application.

If your application or integration uses the Neon API or SDKs that wrap the Neon API, we recommend building in the same type of retry logic.

See also

• Building resilient applications with Postgres: Best practices for handling connection drops with retry logic, connection pooling, and idempotency
• Connection latency and timeouts: Strategies for managing connection latencies and timeouts