Managed Databases

DigitalOcean's Managed Databases are a fully managed, high performance database cluster service. Using managed databases is a powerful alternative to installing, configuring, maintaining, and securing databases by hand.

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 added to a private network or VPC network for the datacenter region by default.

Database Engines

We currently offer three database engines: PostgreSQL, Redis, and MySQL.

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.
3 articles
Redis is an open source, key-value database built with an in-memory design that emphasizes speed. It has support for rich data types, atomic operations, and Lua scripting.
3 articles
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.
3 articles

Feature Availability

Feature PostgreSQL Redis MySQL
High availability with automated failover
End-to-end security
Automatic updates
Logs
Read-only nodes
Daily point-in-time backups
Forking
Metrics
Eviction policies
Query insights
Private networking
VPC

Cluster Configuration

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 $15/month single node clusters.

  • 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.

High Availability

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 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.

Latest Updates

7 April 2020

4 March 2020

27 January 2020

  • v1.13.0 of the DigitalOcean Terraform Provider is now available. This release adds support for tagging Managed Databases clusters.

19 December 2019

  • Released v1.12.0 of the DigitalOcean Terraform Provider. This release contains improvements to Managed Database support including a new resource for configuring trusted sources and the ability to set the global SQL mode or Redis eviction policy on a cluster. There is also a new data source for finding supported Kubernetes versions. Learn more on the Terraform Changelog.

For more information, see the full release notes.