- How-Tos
- Scale Cluster
- Resize Database Clusters
For AI agents: The documentation index is at https://docs.digitalocean.com/llms.txt. Markdown versions of pages use the same URL with
index.html.mdin place of the HTML page (for example, appendindex.html.mdto the directory path instead of opening the HTML document).
How to Resize PostgreSQL Database Clusters
Last verified 31 Jul 2026
PostgreSQL is an open source, object-relational database built for extensibility, data integrity, and speed. Its concurrency support makes it fully ACID-compliant, and it supports dynamic loading and catalog-driven operations to let users customize its data types, functions, and more.
You can resize existing PostgreSQL database clusters at any time to change CPU, RAM, and storage, including scaling up or down when disk utilization and plan limits allow.
Scaling Down
You can scale down compute and storage when the target configuration keeps projected disk utilization at or under 80%. Projected utilization is calculated using the size of your most recent backup plus your current log size. The combined size must be within 80% of the target storage.
Each compute plan enforces minimum and maximum storage values. When scaling down, the target storage must remain within these limits, even if the 80% utilization check would otherwise allow a smaller size. You can choose a smaller compute tier only if the requested storage falls within that tier’s allowed range.
For example, starting from a General Purpose Dedicated CPU plan with 4 vCPU / 16 GiB RAM, 100 GiB storage, and 80 GiB used for data:
| Target configuration | Result |
|---|---|
| Same plan with 90 GiB storage | Allowed (meets 80% limit) |
| General Purpose Dedicated CPU, 2 vCPU / 8 GiB RAM, 90 GiB storage | Allowed (within plan limits) |
| Basic Shared CPU, 1 vCPU / 2 GiB RAM, 90 GiB storage | Not allowed (plan supports maximum storage of 60 GiB) |
| General Purpose Dedicated CPU, 8 vCPU / 32 GiB RAM, 90 GiB storage | Not allowed (plan requires minimum storage of 160 GiB) |
Resize a Database Cluster Using Automation
You can resize a database cluster using the DigitalOcean CLI (doctl) or the API.
Resize a Database Cluster via CLI
To resize a database cluster using doctl, you need to provide a value for the --size flag, which specifies the cluster’s new configuration (number of CPUs, amount of RAM, and hard disk space). Use the doctl databases options slugs command to get a list of available values.
-
Install
doctl, the official DigitalOcean CLI. -
Create a personal access token and save it for use with
doctl. -
Use the token to grant
doctlaccess to your DigitalOcean account.doctl auth init -
Finally, run
doctl databases resize. Basic usage looks like this, but you can read the usage docs for more details:doctl databases resize <database-cluster-id> [flags]The following example resizes a PostgreSQL or MySQL database to have two nodes, 16 vCPUs, 64 GB of memory, and 2048 GiB of storage space:
doctl databases resize ca9f591d-9999-5555-a0ef-1c02d1d1e352 --num-nodes 2 --size db-s-16vcpu-64gb --storage-size-mib 2048000 --wait true
Resize a Database Cluster via API
To resize a database cluster using the API, you need to provide a value for the size field, which specifies the cluster’s configuration (number of CPUs, amount of RAM, and hard disk space). Use the /v2/databases/options endpoint to get a list of available values.
Create a personal access token and save it for use with the API.
cURL
Send a PUT request to https://api.digitalocean.com/v2/databases/{database_cluster_uuid}/resize.
Using cURL:
curl -X PUT \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $DIGITALOCEAN_TOKEN" \
-d '{"size":"db-s-4vcpu-8gb", "num_nodes":3, "storage_size_mib":163840}' \
"https://api.digitalocean.com/v2/databases/9cc10173-e9ea-4176-9dbc-a4cee4c4ff30/resize" Go
Using Godo, the official DigitalOcean API client for Go:
import (
"context"
"github.com/digitalocean/godo"
)
func main() {
pat := "mytoken"
client := godo.NewFromToken(pat)
ctx := context.TODO()
resizeRequest := &godo.DatabaseResizeRequest{
SizeSlug: "db-s-4vcpu-8gb",
NumNodes: 3,
StorageSizeMib: 163840,
}
}Python
Using PyDo, the official DigitalOcean API client for Python:
import os
from pydo import Client
client = Client(token=os.environ.get("DIGITALOCEAN_TOKEN"))
req = {
"size": "db-s-4vcpu-8gb",
"num_nodes": 3,
"storage_size_mib": 163840
}
update_resp = client.databases.update_cluster_size(database_cluster_uuid="a7a8bas", body=req)Resize a Database Cluster Using the Control Panel
To resize a PostgreSQL database cluster, go to the Databases page, and select the cluster you want to resize. On the cluster’s Overview page, click the Settings tab.
In the Configuration section, click Edit. Select a tab to view available Shared CPU or Dedicated CPU plans, then choose options under CPU options and Select a plan.
[Cluster configuration section, showing available plan options]
Under Choose a storage size, you can update the amount of storage.
[The Choose a Storage Size section of the database configuration]
In the Autoscale storage section, select Enable Storage Autoscaling to automatically increase storage when disk utilization on any node in the cluster reaches the specified threshold. The threshold is based on the worst-performing node in the cluster, not the average across nodes.
[The Autoscale storage section with Enable Storage Autoscaling selected and custom threshold and increment options]
Click Customize to set a custom Threshold and Storage Increment. The system bills this increase as additional storage.
NoteWhen autoscaling occurs, the specified storage increment is added to each node in the cluster, not distributed across the cluster. The total added storage is the increment multiplied by the number of nodes.
Autoscaling takes several minutes, depending on the cluster size. It runs without downtime, and no action is required.
In the Maximize uptime for critical workloads section (for plans with 2 GB RAM or higher), you can add standby nodes.
Click Save to apply your changes.
Your cluster’s state changes from Active to Resizing until the process is complete. Provisioning can take several minutes, depending on cluster size, but does not cause downtime.