Skip to main content
CloudOctober 12, 20263 min read

Planning a DigitalOcean Database? Read This Before Oct 15

Get technical support

One cloud or several, one standard

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.