From October 15, new DigitalOcean accounts can no longer create Standard Edition PostgreSQL or MySQL clusters above 4 GiB of RAM or with standby nodes, and from November 30 the same applies to every account. Existing clusters keep everything.
What Changes
DigitalOcean is narrowing what Standard Edition offers for new PostgreSQL and MySQL clusters.
- New Standard Edition clusters can only use Basic Shared CPU plans with 1, 2 or 4 GiB of RAM, on the Regular, Premium AMD, Premium Intel and AMDv5 CPU options.
- New Standard Edition clusters cannot have standby nodes or read-only nodes.
- On October 15, Advanced Edition gains Basic Shared CPU plans from 8 to 64 GiB of RAM for every account, next to all of its current Dedicated CPU plans.
DigitalOcean's advice is short. If you need more than 4 GiB of RAM, read-only nodes or standby nodes for high availability, use Advanced Edition.
When It Reaches Your Account
- October 15, 2026 for accounts that have never created a PostgreSQL or MySQL cluster.
- November 30, 2026 for every other account. A cluster you created and later deleted still counts, so those accounts get the later date.
Existing Clusters Keep Everything
Nothing happens to clusters that already exist. They can still be resized, forked and restored from backups, even onto plans that are no longer offered for new clusters, and they can still add standby and read-only nodes. DigitalOcean says no action is needed and that it will give advance notice before changing anything for existing clusters.
What to Do Before Your Date
- Check your automation. If Terraform, doctl or your own API scripts create Standard Edition clusters larger than 4 GiB or with standby nodes, they will fail once the change reaches your account. DigitalOcean says such code may need updating before then, so test the Advanced Edition version now rather than during an incident.
- Plan new production databases around Advanced Edition. For PostgreSQL it adds a consensus-based high availability manager that elects a new primary after a failure, and a connection pooler that gives applications one endpoint that stays the same through a failover. It costs more than comparable Standard plans, so put that in the budget early.
- Know which date applies to you. An account that has never had a cluster meets the limits on October 15. Every other account has until the end of November.
- Moving an existing database is optional. If you do move a PostgreSQL database later, plan it like any other migration, with a test copy first. Our guide to upgrading PostgreSQL with almost no downtime shows the pattern we use.
Where It Fits
Picking a managed database plan that will still fit in a year, and keeping the code that creates it in step with the provider, is part of our cloud management work.
Sources
Or read how we handle it in Managed Cloud.
Related News
The DNS Root Key Changes on October 11. Is Your Server Ready?
On October 11, 2026 the DNS root starts signing with a new key-signing key, KSK-2024, for only the second time ever. Most sites need to do nothing. A server that validates DNSSEC through its own resolver must already trust the new key, and a one-minute check tells you.
CloudRDS MySQL 8.0 Leaves Standard Support in July and AWS Auto-Enrolls You Into a Paid Bill
Amazon RDS for MySQL 8.0 reaches end of standard support on July 31, 2026. The next day, AWS automatically enrolls any instance still on 8.0 into paid Extended Support, billed per vCPU-hour, unless you set the disabled lifecycle flag at creation or restore. The fix is an in-place upgrade to MySQL 8.4 before the date.
CloudRailway 8-Hour Outage: GCP Auto-Suspended Their Account
Google Cloud auto-suspended Railway's production account on May 19, 2026, taking the platform offline for 8 hours. The cross-cloud dependency lesson, in detail.