Last verified 29 Oct 2026
DigitalOcean Managed Databases are a fully managed, high performance database cluster service. Using managed databases is an alternative to manually installing, configuring, maintaining, and securing databases.
Clusters include daily backups with point-in-time recovery (PITR), standby nodes for high availability, and end-to-end SSL encryption. Managed databases are multi-region and scalable, and their automated failover means even single-node plans add resiliency to your infrastructure. When you create a new managed database cluster, the cluster is placed in a VPC network by default.
We currently offer the following database engines:
PostgreSQL is an open source, object-relational database built with extensibility, data integrity, and speed in mind. 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.
MySQL is an open source, object-relational database built with speed and reliability in mind. Its large and active developer community has created many third-party applications, tools, and libraries that expand MySQL’s functionality.
Kafka is an open-source distributed event and stream-processing platform built to process demanding real-time data feeds. It is inherently scalable, with high throughput and availability.
MongoDB is a source-available cross-platform document-oriented database program for high-volume storage. Classified as a NoSQL database program, MongoDB uses JSON-like documents with optional schemas.
OpenSearch is an open-source search and analytics suite which allows you to forward logs.
Valkey is a high-performance, open-source database that stores key-value data in memory, and is designed for caching, message queues, and primary database use. Fully compatible with Redis, Valkey serves as a drop-in replacement.
Lifecycle status for current and historical versions, including when each version becomes unavailable for new clusters.
| Feature | PostgreSQL | MySQL | Valkey | MongoDB | Kafka | OpenSearch |
|---|---|---|---|---|---|---|
| High availability with automated failover | ■ | ■ | ■ | ■ | ■ | ■ |
| End-to-end security | ■ | ■ | ■ | ■ | ■ | ■ |
| Automatic updates | ■ | ■ | ■ | ■ | ■ | ■ |
| Logs | ■ | ■ | ■ | ■ | ■ | ■ |
| Metrics | ■ | ■ | ■ | ■ | ■ | ■ |
| VPC | ■ | ■ | ■ | ■ | ■ | ■ |
| Forking | ■ | ■ | ■ | ■ | ■ | |
| Read-only nodes | ■ | ■ | ||||
| Daily point-in-time backups | ■ | ■ | ■ | ■ | ||
| Query insights | ■ | ■ | ||||
| Online migration | ■ | ■ | ■ |
DigitalOcean Managed Databases offers three types of nodes:
The primary node of a database cluster processes queries, updates the database, returns results to clients, and acts as the single source of data for all other nodes.
Standby nodes are copies of the primary node that automatically take over if the primary node fails. Database clusters may have zero, one, or two standby nodes. Standby nodes can be added to an existing cluster at any time, with the exception of the smallest plan of single node clusters. Kafka and OpenSearch do not support standby nodes.
Read-only nodes are copies of the primary node that process queries and return results but cannot make changes to the database itself. They provide geographically distinct, horizontal read scaling. Read-only nodes can be added to a cluster at any time.
A database cluster is comprised of one primary node and its standby nodes. Read-only nodes are not considered part of the cluster.
All database clusters have automated failover, meaning they automatically detect and replace degraded or failing nodes.
High availability requires redundancy in addition to automatic failover. Database clusters must have at least one standby node to be highly available because standby nodes provide redundancy for the primary node:
Without standby nodes, the primary node is a single point of failure, so the cluster is not highly available.
If the primary node fails, the service becomes unavailable until the primary node’s replacement is reprovisioned. The amount of time it takes to reprovision a node depends on the amount of data being stored; larger databases require more time.
With one standby node, the cluster is highly available.
If the primary node fails, the service remains available. The standby node is immediately promoted to primary and begins serving requests while a replacement standby node is provisioned in the background.
If both nodes fail simultaneously, the service becomes unavailable until at least one of the nodes is reprovisioned.
With two standby nodes, the cluster is highly available and very resilient against downtime.
Even if two nodes fail simultaneously, the service remains available while two replacements are provisioned in the background.
The service only becomes unavailable in the unlikely event of all three nodes failing at the same time.
In other words, the effect of a primary node’s failure on service availability depends on the cluster configuration. Provisioning a new replacement node takes time, but failing over to a standby node is immediate.
Additional redundancy in the database cluster also minimizes the risk of data loss. If there are no running nodes to copy data from, the database cluster reprovisions nodes using the most recent backup and the write-ahead log to recover the database to as close to the point of failure as possible. However, the write-ahead log backs up every five minutes, so the most recent writes to the database may be lost if the cluster needs to recover this way.
Platform maintenance updates, node failover, or other brief outages (up to 5-10 seconds) can occur and cause your applications to disconnect from your database nodes. If your application fails to connect during one of these events and is not configured to attempt a reconnect, this may cause disruptions in your application’s service even if the node or standby node is back online and ready to accept requests.
To maintain availability, you should configure your client applications to attempt reconnection a reasonable number of times before timing out and causing a service disruption.
You can migrate existing on-premise or cloud-hosted databases to clusters in your DigitalOcean account. Migrating a database establishes a connection with an existing database and replicates its contents to the new database cluster. If the existing database is continuously being written to, the migration process continues until there is no more data to replicate or you manually stop the migration.
MySQL, PostgreSQL, and Valkey support native online migration, which has no downtime. To migrate your database cluster, see the guides for MySQL, PostgreSQL, and Valkey.
Beginning 15 October 2026 for accounts that have never created a PostgreSQL or MySQL database cluster and 30 November 2026 for all accounts, PostgreSQL and MySQL Standard Edition no longer offer plans with more than 4 GiB of RAM or support standby and read-only nodes. On 15 October 2026, Advanced Edition adds Basic - Shared CPU plans with 8 GiB to 64 GiB of RAM. Existing clusters are not affected.
Learn more on PostgreSQL and MySQL Plan Changes Beginning 15 October 2026.
Managed MySQL 8.0 database clusters are scheduled for forced upgrades to MySQL 8.4 beginning 30 October 2026 during each cluster’s maintenance window.
Learn more on MySQL 8.0 End of Life and Forced Upgrades Beginning 30 October 2026.
Kafka 4.3 is now available for database clusters. New clusters use Kafka 4.3 by default, and existing clusters can upgrade to it. Kafka versions 3.9 and 4.2 remain available. Kafka 4.3 reaches end of availability for new clusters on 25 June 2027 and end of life on 25 September 2027. For version support, see Kafka version support and end-of-life dates.
Managed databases are available in Memphis (mem1) on AMDv5 plans only. Storage-Optimized plans are now available for Kafka and OpenSearch clusters in mem1 only. See the regional availability matrix for current coverage by engine.
PostgreSQL Advanced Edition clusters now support 20 additional extensions beyond the pre-installed pg_repack, pg_stat_statements, pgaudit, plpgsql, and vector extensions, including pg_trgm, pgcrypto, citext, and uuid-ossp. You can enable them with CREATE EXTENSION. See Supported PostgreSQL Extensions.
For more information, see the full release notes.
Try using different keywords or simplifying your search terms.