Using Replit Agent? Learn how to add a configured Postgres database to your apps with a single prompt
Docs/Platform/Computes

Manage computes

A primary read-write compute is created for your project's default branch.

To connect to a database that resides in a branch, you must connect via a compute associated with the branch. The following diagram shows the project's default branch (main) and a child branch, both of which have an associated compute.

Project
    |----default branch (main) ---- compute <--- application/client
             |    |
             |    |---- database (neondb)
             |
             ---- child branch ---- compute <--- application/client
                            |
                            |---- database (mydb)

Neon supports both read-write and read replica computes. A branch can have a single primary read-write compute but supports multiple read replica computes.

Plan limits define resources (vCPUs and RAM) available to a compute. The Neon Free Plan provides a shared vCPU and up to 1 GB of RAM per compute. Paid plans support larger compute sizes and autoscaling.

View a compute

A compute is associated with a branch. To view a compute, select Branches in the Neon Console, and select a branch. If the branch has a compute, it is shown on the Computes tab on the branch page.

Compute details shown on the branch page include:

  • The type of compute, which can be Primary (read-write) or Read Replica (read-only).
  • The compute status, typically Active or Idle.
  • Compute ID: The compute ID, which always starts with an ep- prefix; for example: ep-quiet-butterfly-w2qres1h
  • Size: The size of the compute. Users on paid plans can configure the amount of vCPU and RAM for a compute when creating or editing a compute. Shows autoscaling minimum and maximum vCPU values if autoscaling is enabled.
  • Last active: The date and time the compute was last active.

Create a compute

You can only create a primary read-write compute for a branch that does not have one, but a branch can have multiple read replica computes.

To create an endpoint:

  1. In the Neon Console, select Branches.
  2. Select a branch.
  3. Click Add a compute or Add Read Replica if you already have a primary read-write compute.
  4. On the Add new compute dialog, specify your compute settings, including compute type, size, autoscaling, and scale to zero, and click Create. Selecting the Read replica compute type creates a read replica.

Edit a compute

You can edit a compute to change the compute size or scale to zero configuration.

To edit a compute:

  1. In the Neon Console, select Branches.

  2. Select a branch.

  3. From the Computes tab, select Edit for the compute you want to edit.

    The Edit window opens, letting you modify settings such as compute size, the autoscaling configuration (if applicable), and your scale to zero setting.

  4. Once you've made your changes, click Save. All changes take immediate effect.

For information about selecting an appropriate compute size or autoscaling configuration, see How to size your compute.

What happens to the compute when making changes

Some key points to understand about how your endpoint responds when you make changes to your compute settings:

  • Changing the size of your fixed compute restarts the endpoint and temporarily disconnects all existing connections.

    note

    When your compute resizes automatically as part of the autoscaling feature, there are no restarts or disconnects; it just scales.

  • Editing minimum or maximum autoscaling sizes also requires a restart; existing connections are temporarily disconnected.
  • If you disable scale to zero, you will need to restart your compute manually to get the latest compute-related release updates from Neon. See Restart a compute.

To avoid prolonged interruptions resulting from compute restarts, we recommend configuring your clients and applications to reconnect automatically in case of a dropped connection.

Compute size and autoscaling configuration

Users on paid plans can change compute size settings when editing a compute.

Compute size is the number of Compute Units (CUs) assigned to a Neon compute. The number of CUs determines the processing capacity of the compute. One CU has 1 vCPU and 4 GB of RAM, 2 CUs have 2 vCPUs and 8 GB of RAM, and so on. The amount of RAM in GB is always 4 times the vCPUs, as shown in the table below.

Compute UnitsvCPURAM
.25.251 GB
.5.52 GB
114 GB
228 GB
3312 GB
4416 GB
5520 GB
6624 GB
7728 GB
8832 GB
9936 GB
101040 GB
111144 GB
121248 GB
131352 GB
141456 GB
151560 GB
161664 GB
181872 GB
202080 GB
222288 GB
242496 GB
2626104 GB
2828112 GB
3030120 GB
3232128 GB
3434136 GB
3636144 GB
3838152 GB
4040160 GB
4242168 GB
4444176 GB
4646184 GB
4848192 GB
5050200 GB
5252208 GB
5454216 GB
5656224 GB

Neon supports fixed-size and autoscaling compute configurations.

  • Fixed size: Select a fixed compute size ranging from .25 CUs to 56 CUs. A fixed-size compute does not scale to meet workload demand.
  • Autoscaling: Specify a minimum and maximum compute size. Neon scales the compute size up and down within the selected compute size boundaries in response to the current load. Currently, the Autoscaling feature supports a range of 1/4 (.25) CU to 16 CUs. The 1/4 CU and 1/2 CU settings are shared compute. For information about how Neon implements the Autoscaling feature, see Autoscaling.

info

The neon_utils extension provides a num_cpus() function you can use to monitor how the Autoscaling feature allocates compute resources in response to workload. For more information, see The neon_utils extension.

How to size your compute

The size of your compute determines the amount of frequently accessed data you can cache in memory and the maximum number of simultaneous connections you can support. As a result, if your compute size is too small, this can lead to suboptimal query performance and connection limit issues.

In Postgres, the shared_buffers setting defines the amount of data that can be held in memory. In Neon, the shared_buffers parameter is always set to 128 MB, but Neon uses a Local File Cache (LFC) to extend the amount of memory available for caching data. The LFC can use up to 80% of your compute's RAM.

The Postgres max_connections setting defines your compute's maximum simultaneous connection limit and is set according to your compute size. Larger computes support higher maximum connection limits.

The following table outlines the vCPU, RAM, LFC size (80% of RAM), and the max_connections limit for each compute size that Neon supports.

note

Compute size support differs by Neon plan. Autoscaling is supported up to 16 CU. Neon supports fixed compute sizes (no autoscaling) for computes sizes larger than 16 CU.

Min. Compute Size (CU)vCPURAMLFC sizemax_connections
0.250.251 GB0.8 GB112
0.500.502 GB1.6 GB225
114 GB3.2 GB450
228 GB6.4 GB901
3312 GB9.6 GB1351
4416 GB12.8 GB1802
5520 GB16 GB2253
6624 GB19.2 GB2703
7728 GB22.4 GB3154
8832 GB25.6 GB3604
9936 GB28.8 GB4000
101040 GB32 GB4000
111144 GB35.2 GB4000
121248 GB38.4 GB4000
131352 GB41.6 GB4000
141456 GB44.8 GB4000
151560 GB48 GB4000
161664 GB51.2 GB4000
181872 GB57.6 GB4000
202080 GB64 GB4000
222288 GB70.4 GB4000
242496 GB76.8 GB4000
2626104 GB83.2 GB4000
2828112 GB89.6 GB4000
3030120 GB96 GB4000
3232128 GB102.4 GB4000
3434136 GB108.8 GB4000
3636144 GB115.2 GB4000
3838152 GB121.6 GB4000
4040160 GB128 GB4000
4242168 GB134.4 GB4000
4444176 GB140.8 GB4000
4646184 GB147.2 GB4000
4848192 GB153.6 GB4000
5050200 GB160 GB4000
5252208 GB166.4 GB4000
5454216 GB172.8 GB4000
5656224 GB179.2 GB4000

When selecting a compute size, ideally, you want to keep as much of your dataset in memory as possible. This improves performance by reducing the amount of reads from storage. If your dataset is not too large, select a compute size that will hold the entire dataset in memory. For larger datasets that cannot be fully held in memory, select a compute size that can hold your working set. Selecting a compute size for a working set involves advanced steps, which are outlined below. See Sizing your compute based on the working set.

Regarding connection limits, you'll want a compute size that can support your anticipated maximum number of concurrent connections. If you are using Autoscaling, it is important to remember that your max_connections setting is based on the minimum compute size in your autoscaling configuration. The max_connections setting does not scale with your compute. To avoid the max_connections constraint, you can use a pooled connection with your application, which supports up to 10,000 concurrent user connections. See Connection pooling.

Sizing your compute based on the working set

If it's not possible to hold your entire dataset in memory, the next best option is to ensure that your working set is in memory. A working set is your frequently accessed or recently used data and indexes. To determine whether your working set is fully in memory, you can query the cache hit ratio for your Neon compute. The cache hit ratio tells you how many queries are served from memory. Queries not served from memory bypass the cache to retrieve data from Neon storage (the Pageserver), which can affect query performance.

As mentioned above, Neon computes use a Local File Cache (LFC) to extend Postgres shared buffers. You can monitor the Local File Cache hit rate and your working set size from Neon's Monitoring page, where you'll find the following charts:

Neon also provides a neon extension with a neon_stat_file_cache view that you can use to query the cache hit ratio for your compute's Local File Cache. For more information, see The neon extension.

Autoscaling considerations

Autoscaling is most effective when your data (either your full dataset or your working set) can be fully cached in memory on the minimum compute size in your autoscaling configuration.

Consider this scenario: If your data size is approximately 6 GB, starting with a compute size of .25 CU can lead to suboptimal performance because your data cannot be adequately cached. While your compute will scale up from .25 CU on demand, you may experience poor query performance until your compute scales up and fully caches your working set. You can avoid this issue if your minimum compute size can hold your working set in memory.

As mentioned above, your max_connections setting is based on the minimum compute size in your autoscaling configuration and does not scale along with your compute. To avoid this max_connections constraint, you can use a pooled connection for your application. See Connection pooling.

Scale to zero configuration

Neon's Scale to Zero feature automatically transitions a compute into an idle state after 5 minutes of inactivity. You can disable scale to zero to maintain an "always-active" compute. An "always-active" configuration eliminates the few hundred milliseconds seconds of latency required to reactivate a compute but is likely to increase your compute time usage on systems where the database is not always active.

For more information, refer to Configuring scale to zero for Neon computes.

important

If you disable scale to zero or your compute is never idle long enough to be automatically suspended, you will have to manually restart your compute to pick up the latest updates to Neon's compute images. Neon typically releases compute-related updates weekly. Not all releases contain critical updates, but a weekly compute restart is recommended to ensure that you do not miss anything important. For how to restart a compute, see Restart a compute.

Restart a compute

It is sometimes necessary to restart a compute. For example, if you upgrade to a paid plan account, you may want to restart your compute to immediately apply your upgraded limits, or maybe you've disabled autosuspesion and want to restart your compute to pick up the latest compute-related updates, which Neon typically releases weekly.

important

Please be aware that restarting a compute interrupts any connections currently using the compute. To avoid prolonged interruptions resulting from compute restarts, we recommend configuring your clients and applications to reconnect automatically in case of a dropped connection.

You can restart a compute using one of the following methods:

  • Stop activity on your compute (stop running queries) and wait for your compute to suspend due to inactivity. By default, Neon suspends a compute after 5 minutes of inactivity. You can watch the status of your compute on the Branches page in the Neon Console. Select your branch and monitor your compute's Status field. Wait for it to report an Idle status. The compute will restart the next time it's accessed, and the status will change to Active.
  • Issue a Restart endpoint call using the Neon API. You can do this directly from the Neon API Reference using the Try It! feature or via the command line with a cURL command similar to the one shown below. You'll need your project ID, compute endpoint ID, and an API key.
    curl --request POST \
       --url https://console.neon.tech/api/v2/projects/cool-forest-86753099/endpoints/ep-calm-flower-a5b75h79/restart \
       --header 'accept: application/json' \
       --header 'authorization: Bearer $NEON_API_KEY'
  • Users on paid plans can temporarily set a compute's scale to zero setting to a low value to initiate a suspension (the default setting is 5 minutes). See Scale to zero configuration for instructions. After doing so, check the Operations page in the Neon Console. Look for suspend_compute action. Any activity on the compute will restart it, such as running a query. Watch for a start_compute action on the Operations page.

Delete a compute

Deleting a compute is a permanent action.

To delete a compute :

  1. In the Neon Console, select Branches.
  2. Select a branch.
  3. On the Computes tab, click Edit for the compute you want to delete.
  4. At the bottom of the Edit compute drawer, click Delete compute.

Manage computes with the Neon API

Compute actions performed in the Neon Console can also be performed using the Neon API. The following examples demonstrate how to create, view, update, and delete computes using the Neon API. For other compute-related API methods, refer to the Neon API reference.

note

The API examples that follow may not show all of the user-configurable request body attributes that are available to you. To view all attributes for a particular method, refer to method's request body schema in the Neon API reference.

The jq option specified in each example is an optional third-party tool that formats the JSON response, making it easier to read. For information about this utility, see jq.

Prerequisites

A Neon API request requires an API key. For information about obtaining an API key, see Create an API key. In the cURL examples below, $NEON_API_KEY is specified in place of an actual API key, which you must provide when making a Neon API request.

note

To learn more about the types of API keys you can create — personal, organization, or project-scoped — see Manage API Keys.

Create a compute with the API

The following Neon API method creates a compute.

POST /projects/{project_id}/endpoints

The API method appears as follows when specified in a cURL command. The branch you specify cannot have an existing compute. A compute must be associated with a branch. Neon supports read-write and read replica compute. A branch can have a single primary read-write compute but supports multiple read replica computes.

curl -X 'POST' \
  'https://console.neon.tech/api/v2/projects/hidden-cell-763301/endpoints' \
  -H 'accept: application/json' \
  -H "Authorization: Bearer $NEON_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
  "endpoint": {
    "branch_id": "br-blue-tooth-671580",
    "type": "read_write"
  }
}'
Response body
{
  "endpoint": {
    "host": "ep-aged-math-668285.us-east-2.aws.neon.tech",
    "id": "ep-aged-math-668285",
    "project_id": "hidden-cell-763301",
    "branch_id": "br-blue-tooth-671580",
    "autoscaling_limit_min_cu": 1,
    "autoscaling_limit_max_cu": 1,
    "region_id": "aws-us-east-2",
    "type": "read_write",
    "current_state": "init",
    "pending_state": "active",
    "settings": {
      "pg_settings": {}
    },
    "pooler_enabled": false,
    "pooler_mode": "transaction",
    "disabled": false,
    "passwordless_access": true,
    "created_at": "2023-01-04T18:39:41Z",
    "updated_at": "2023-01-04T18:39:41Z",
    "proxy_host": "us-east-2.aws.neon.tech"
  },
  "operations": [
    {
      "id": "e0e4da91-8576-4348-913b-aaf61a46d314",
      "project_id": "hidden-cell-763301",
      "branch_id": "br-blue-tooth-671580",
      "endpoint_id": "ep-aged-math-668285",
      "action": "start_compute",
      "status": "running",
      "failures_count": 0,
      "created_at": "2023-01-04T18:39:41Z",
      "updated_at": "2023-01-04T18:39:41Z"
    }
  ]
}

List computes with the API

The following Neon API method lists computes for the specified project. A compute belongs to a Neon project. To view the API documentation for this method, refer to the Neon API reference.

GET /projects/{project_id}/endpoints

The API method appears as follows when specified in a cURL command:

curl -X 'GET' \
  'https://console.neon.tech/api/v2/projects/hidden-cell-763301/endpoints' \
  -H 'accept: application/json' \
  -H "Authorization: Bearer $NEON_API_KEY"
Response body
{
  "endpoints": [
    {
      "host": "ep-young-art-646685.us-east-2.aws.neon.tech",
      "id": "ep-young-art-646685",
      "project_id": "hidden-cell-763301",
      "branch_id": "br-shy-credit-899131",
      "autoscaling_limit_min_cu": 1,
      "autoscaling_limit_max_cu": 1,
      "region_id": "aws-us-east-2",
      "type": "read_write",
      "current_state": "idle",
      "settings": {
        "pg_settings": {}
      },
      "pooler_enabled": false,
      "pooler_mode": "transaction",
      "disabled": false,
      "passwordless_access": true,
      "last_active": "2023-01-04T18:38:25Z",
      "created_at": "2023-01-04T18:38:23Z",
      "updated_at": "2023-01-04T18:43:36Z",
      "proxy_host": "us-east-2.aws.neon.tech"
    },
    {
      "host": "ep-aged-math-668285.us-east-2.aws.neon.tech",
      "id": "ep-aged-math-668285",
      "project_id": "hidden-cell-763301",
      "branch_id": "br-blue-tooth-671580",
      "autoscaling_limit_min_cu": 1,
      "autoscaling_limit_max_cu": 1,
      "region_id": "aws-us-east-2",
      "type": "read_write",
      "current_state": "idle",
      "settings": {
        "pg_settings": {}
      },
      "pooler_enabled": false,
      "pooler_mode": "transaction",
      "disabled": false,
      "passwordless_access": true,
      "last_active": "2023-01-04T18:39:42Z",
      "created_at": "2023-01-04T18:39:41Z",
      "updated_at": "2023-01-04T18:44:48Z",
      "proxy_host": "us-east-2.aws.neon.tech"
    }
  ]
}

Update a compute with the API

The following Neon API method updates the specified compute. To view the API documentation for this method, refer to the Neon API reference.

PATCH /projects/{project_id}/endpoints/{endpoint_id}

The API method appears as follows when specified in a cURL command. The example reassigns the compute to another branch by changing the branch_id. The branch that you specify cannot have an existing compute. A compute must be associated with a branch, and a branch can have only one primary read-write compute. Multiple read-replica computes are allowed.

curl -X 'PATCH' \
  'https://console.neon.tech/api/v2/projects/hidden-cell-763301/endpoints/ep-young-art-646685' \
  -H 'accept: application/json' \
  -H "Authorization: Bearer $NEON_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
  "endpoint": {
    "branch_id": "br-green-lab-617946"
  }
}'
Response body
{
  "endpoint": {
    "host": "ep-young-art-646685.us-east-2.aws.neon.tech",
    "id": "ep-young-art-646685",
    "project_id": "hidden-cell-763301",
    "branch_id": "br-green-lab-617946",
    "autoscaling_limit_min_cu": 1,
    "autoscaling_limit_max_cu": 1,
    "region_id": "aws-us-east-2",
    "type": "read_write",
    "current_state": "idle",
    "pending_state": "idle",
    "settings": {
      "pg_settings": {}
    },
    "pooler_enabled": false,
    "pooler_mode": "transaction",
    "disabled": false,
    "passwordless_access": true,
    "last_active": "2023-01-04T18:38:25Z",
    "created_at": "2023-01-04T18:38:23Z",
    "updated_at": "2023-01-04T18:47:36Z",
    "proxy_host": "us-east-2.aws.neon.tech"
  },
  "operations": [
    {
      "id": "03bf0bbc-cc46-4863-a5c4-f31fc1881228",
      "project_id": "hidden-cell-763301",
      "branch_id": "br-green-lab-617946",
      "endpoint_id": "ep-young-art-646685",
      "action": "apply_config",
      "status": "running",
      "failures_count": 0,
      "created_at": "2023-01-04T18:47:36Z",
      "updated_at": "2023-01-04T18:47:36Z"
    },
    {
      "id": "c96be00c-6340-4fb2-b80a-5ae96f469969",
      "project_id": "hidden-cell-763301",
      "branch_id": "br-green-lab-617946",
      "endpoint_id": "ep-young-art-646685",
      "action": "suspend_compute",
      "status": "scheduling",
      "failures_count": 0,
      "created_at": "2023-01-04T18:47:36Z",
      "updated_at": "2023-01-04T18:47:36Z"
    }
  ]
}

Delete a compute with the API

The following Neon API method deletes the specified compute. To view the API documentation for this method, refer to the Neon API reference.

DELETE /projects/{project_id}/endpoints/{endpoint_id}

The API method appears as follows when specified in a cURL command.

curl -X 'DELETE' \
  'https://console.neon.tech/api/v2/projects/hidden-cell-763301/endpoints/ep-young-art-646685' \
  -H 'accept: application/json' \
  -H "Authorization: Bearer $NEON_API_KEY"
Response body
{
  "endpoint": {
    "host": "ep-young-art-646685.us-east-2.aws.neon.tech",
    "id": "ep-young-art-646685",
    "project_id": "hidden-cell-763301",
    "branch_id": "br-green-lab-617946",
    "autoscaling_limit_min_cu": 1,
    "autoscaling_limit_max_cu": 1,
    "region_id": "aws-us-east-2",
    "type": "read_write",
    "current_state": "idle",
    "settings": {
      "pg_settings": {}
    },
    "pooler_enabled": false,
    "pooler_mode": "transaction",
    "disabled": false,
    "passwordless_access": true,
    "last_active": "2023-01-04T18:38:25Z",
    "created_at": "2023-01-04T18:38:23Z",
    "updated_at": "2023-01-04T18:47:45Z",
    "proxy_host": "us-east-2.aws.neon.tech"
  },
  "operations": []
}

This section outlines compute-related issues you may encounter and possible resolutions.

No space left on device

You may encounter an error similar to the following when your compute's local disk storage is full:

ERROR: could not write to file "base/pgsql_tmp/pgsql_tmp1234.56.fileset/o12of34.p1.0": No space left on device (SQLSTATE 53100)

Neon computes allocate approximately 20 GB of local disk space for temporary files used by Postgres. Data-intensive operations can sometimes consume all of this space, resulting in No space left on device errors.

To resolve this issue, you can try the following strategies:

  • Identify and terminate resource-intensive processes: These could be long-running queries, operations, or possibly sync or replication activities. You can start your investigation by listing running queries by duration.
  • Optimize queries to reduce temporary file usage.
  • Adjust pipeline settings for third-party sync or replication: If you're syncing or replicating data with an external service, modify the pipeline settings to control disk space usage.

If the issue persists, refer to our Neon Support channels.

Compute is not suspending

In some cases, you may observe that your compute remains constantly active for no apparent reason. Possible causes for a constantly active compute when not expected include:

  • Connection requests: Frequent connection requests from clients, applications, or integrations can prevent a compute from suspending automatically. Each connection resets the scale to zero timer.
  • Background processes: Some applications or background jobs may run periodic tasks that keep the connection active.

Possible steps you can take to identify the issues include:

  1. Checking for active processes

    You can run the following query to identify active sessions and their states:

    SELECT
      pid,
      usename,
      query,
      state,
      query_start
    FROM
      pg_stat_activity
    WHERE
      query_start >= now() - interval '24 hours'
    ORDER BY
      query_start DESC;

    Look for processes initiated by your users, applications, or integrations that may be keeping your compute active.

  2. Review connection patterns

    • Ensure that no applications are sending frequent, unnecessary connection requests.
    • Consider batching connections if possible, or use connection pooling to limit persistent connections.
  3. Optimize any background jobs

    If background jobs are needed, reduce their frequency or adjust their timing to allow Neon's scale to zero feature to activate after the defined period of inactivity (the default is 5 minutes). For more information, refer to our Scale to zero guide.

Need help?

Join our Discord Server to ask questions or see what others are doing with Neon. Users on paid plans can open a support ticket from the console. For more details, see Getting Support.

Last updated on

Was this page helpful?