Database Maintenance & Scaling
TL;DR — The Settings page on a cluster lets you choose a maintenance window, add a read replica, migrate to a new region, resize the tier, and destroy the cluster. All but destroy are non-destructive.
Where to Find It
- Open your cluster
- Click the Settings button in the cluster header
You'll see four sections, top to bottom.
Add a Read Node
Adds a read-only replica of your cluster. See the dedicated Read Replicas guide for details, sizing, and connection examples.
Summary: pick an unused Starter (or higher) plan that matches your engine and click Add Read Node.
Maintenance Window
Production databases need periodic minor patches (security fixes, point releases, configuration nudges). We apply them automatically during a window you choose, so you control when the brief impact occurs.
Configure
The maintenance window form has two dropdowns:
- Day — Monday through Sunday
- Hour (UTC) — 00:00 through 23:00 in one-hour increments
Click Save to persist your choice.
What Happens During Maintenance
- Patches install on the standby first (on HA clusters), then a failover swaps standby and primary so the new primary is patched
- On Starter (single-node) clusters, the maintenance window may include a few seconds to ~2 minutes of unavailability
- Most maintenance is non-impacting — config changes only
Pending Maintenance Indicator
- On the Overview and Insights tabs, a banner labelled Update pending appears if maintenance is scheduled
- The banner shows the next day + hour the window will fire
- Postpone by changing the window to a later slot (each save resets the timer)
Choosing a Window
| Workload | Recommended Window |
|---|---|
| 9–5 SaaS for one region | Local 02:00–04:00 of your customer base |
| Global SaaS | Pick your lowest-traffic 60 minutes (check your analytics) |
| Internal tools | Anywhere outside your team's working hours |
| HA-only production | Less critical — failover keeps you online |
Change Datacenter
Migrates the cluster to a different region. The cluster stays online until cutover; cutover involves a brief unavailability (typically under a minute).
Migrate
- In Change Datacenter, search the dropdown for the new region (by name or country)
- Click Migrate
The cluster's status changes to Migrating until the move completes. Returns to Online with the new region shown.
When to Migrate
- Latency complaints from customers in a different region → move closer
- Compliance / data residency change (e.g. moving to an EU region for GDPR)
- A region change for your application servers — keep the database in the same region as the app
What Doesn't Change
- Connection URI host stays valid — the underlying hostname remains the same and follows the cluster
- Backups, users, databases, firewall rules, pools, log destinations — all preserved
- Read replicas — migrate independently (open each replica's settings)
⚠️ Update IP-based firewall rules if your application servers are also moving regions. Their public IPs will change.
Resize Cluster
Upgrades the cluster to a larger tier (or, on Kafka, the Cluster tier).
Resize
- In Resize Cluster, pick the target tier (e.g. HA)
- Click Resize
The cluster's status changes to Resizing until the upgrade completes. On HA clusters, the resize is rolling — the standby is upgraded first, then promoted, then the old primary is upgraded.
Rules
- ✅ Starter → HA — allowed
- ✅ HA → larger HA — allowed (when bigger SKUs are available)
- ❌ HA → Starter (downsize) — not available in the UI; open a support ticket to request
Resizes also automatically upgrade your subscription to the new tier's pricing — no separate purchase needed.
Storage
Storage is tier-bound — the Starter tier comes with 10 GiB and HA comes with 61 GiB. You don't pick storage independently. To grow storage, upgrade the tier.
Best Practices
- Resize during off-peak. The cluster works through the resize, but there's a momentary failover at the end on HA clusters.
- Test against an HA replica first. If your workload is large enough that "will it fit on the next tier" is in doubt, spin up an HA replica and load-test against it before resizing the primary.
- Pre-warm caches. PostgreSQL's buffer cache restarts empty after a resize — expect a few minutes of higher read I/O while it refills.
Destroy Cluster
Permanently deletes the cluster and all its replicas, pools, users, databases, and firewall rules. Data is unrecoverable after destroy.
Destroy
- In Destroy Cluster, type the cluster name exactly into the confirmation field
- Click Destroy
You're redirected back to the cluster list, and the cluster disappears within a few seconds.
What Destroy Does
- ✅ Deletes the primary cluster
- ✅ Deletes all read replicas of that primary
- ✅ Closes any open connections immediately
- ✅ Removes the underlying VPS resources
What Destroy Doesn't Do
- ❌ Does not cancel the subscription. To stop billing, cancel the plan from
/cloudpanel/account/plans. - ❌ Does not delete backups — they remain in the retention window and we can restore from them into a new cluster if needed
- ❌ Does not notify your application — be sure to point your app at a new cluster (or take downtime) before destroying
Recommended Pre-Destroy Checklist
- Export anything you might need later (
pg_dump,mysqldump, Mongo dump, etc.) - Confirm there's no traffic by watching the Insights → Active Connections chart
- Coordinate with anyone who might have configured ETL, BI, or third-party integrations against the cluster
- Cancel the matching subscription if you don't plan to use the plan again
Frequently Asked Questions
Can I resize and migrate at the same time?
Do them sequentially. Migrate first, then resize once the cluster is online in the new region.
Will a resize change my connection URI?
No — host, port, and credentials stay the same. Just briefly higher latency / a momentary blip on HA.
Will a region change affect my IP-based firewall rules?
Your cluster's rules are unchanged. But your application servers' source IPs may change if they're moving regions too — update the rules accordingly.
How long does a destroy take?
A few seconds. There is no undo.
Can I undelete a destroyed cluster?
You can restore from backup into a new cluster — see Backups & Restore.
Why is downsizing not in the UI?
Downsizing has data-fit and performance implications we want to verify by hand. Open a support ticket and we'll guide you through it.