DigitalOcean Advanced Databases Go GA

Releasebot’s September 17, 2026 entry records DigitalOcean’s general-availability release of PostgreSQL and MySQL Advanced Edition clusters across its Managed Databases service.

The immediate architectural change is a stable intermediary between applications and database nodes. When Advanced Edition selects a replacement primary, its pooler or proxy can change the backend without waiting for DNS propagation; connections attached to the former primary may still be interrupted, so applications need reliable reconnection behavior.

Advanced Edition supports current PostgreSQL and MySQL releases

DigitalOcean’s PostgreSQL Advanced Edition documentation lists PostgreSQL 16, 17 and 18, with version 18 as the default for new Advanced clusters. It describes streaming replication with consensus-based leader election, a connection pooler that tracks the current primary, one-, two- and three-node configurations, and mandatory TLS using the system trust store.

The MySQL Advanced Edition specification lists MySQL 8.4 and documents consensus-based replication, automatic primary election and proxy-fronted routing. Advanced MySQL supports one- or three-node clusters rather than the one-, two- or three-node choices available in Standard; its documented high-availability configuration requires three nodes.

General availability therefore covers two engines, but not every version offered by Standard Edition. It also does not mean that every Advanced cluster is redundant: a single-node deployment can use the Advanced connection architecture without having another database node ready to become primary.

Standard and Advanced take different routes to a new primary

The main distinction is not whether failover is automatic, but how clients find the promoted node. In Standard Edition, a replacement primary is promoted while the hostname and connection parameters remain consistent. The hostname must then resolve to the replacement, leaving some clients exposed to cached DNS answers until the update propagates.

Advanced Edition moves that routing decision behind a stable service endpoint. PostgreSQL’s pooler follows the primary selected by its consensus-based high-availability manager, while MySQL’s proxy follows the primary selected by its consensus group. The application continues using the same hostname and port as the backing node changes.

Replication: PostgreSQL Standard uses primary-replica streaming replication; Advanced adds consensus-based leader election. MySQL Standard uses primary-replica replication; Advanced uses consensus-based replication across participating nodes.
Failover routing: Standard changes the destination represented by DNS. Advanced changes the node selected behind a pooler or proxy endpoint.
DNS behavior: Standard clients can temporarily retain a stale destination. Advanced routing does not require a DNS cutover before a reconnecting client can reach the new primary.
Topology: Advanced routing and high availability are separate properties. The stable endpoint determines where a connection goes, while redundant nodes determine whether another primary is available.
TLS: replacement connections still perform TLS negotiation and verification. PostgreSQL teams moving from Standard must account for Advanced Edition’s system-trust-store model rather than carrying over the downloaded-CA configuration unchanged.

This design removes a particular delay rather than making failover invisible in every case. A stable endpoint can direct a new session to the right node, but it cannot guarantee survival of a TCP or database session whose original backend has failed or stopped serving as primary.

Existing connections can still break

During failover, an application may have two very different experiences. A connection established after the routing change can reach the new primary through the unchanged endpoint, while a connection already bound to the former primary may close or become unusable. Long-lived client pools make the distinction important because they can retain failed sessions after the routing layer has moved to a healthy backend.

A failover-ready application therefore needs more than the correct endpoint:

Pooling: remove closed or failed sessions from the pool instead of returning them to borrowers, then create replacements through the normal Advanced endpoint.
TLS: repeat certificate and hostname verification when opening each replacement connection. A stable hostname does not eliminate the new connection handshake.
Reconnection: treat eligible connection failures as transient, apply bounded retries and keep retry timing within the application’s request deadlines.
Transaction safety: do not blindly replay a write when the client cannot determine whether it committed before the connection disappeared. Recovery needs idempotency or another way to prevent duplicate effects.
Node topology: verify that the cluster has enough nodes for the intended availability level. Proxy-fronted routing cannot promote a standby that does not exist.

The relevant operational test is the complete recovery path: how quickly the client notices a dead session, whether the pool evicts it, whether a replacement connection completes TLS verification and how the application handles a transaction with an uncertain result. The managed routing layer selects the new backend; application code and database drivers still govern recovery above that layer.

GA removes the DNS wait, not the reconnect requirement

DigitalOcean Managed Databases Advanced Edition is now a production offering for the documented PostgreSQL and MySQL versions. Compared with Standard Edition, its specific failover advantage is consensus-coordinated primary selection combined with pooler- or proxy-fronted routing that does not wait for DNS propagation.

The remaining boundary is just as specific: active connections may be interrupted, while clients that reconnect to the stable endpoint can be directed to the replacement primary. For infrastructure teams, production readiness still depends on redundant node topology and dependable pool eviction, TLS negotiation, retry limits and transaction-recovery behavior.