DigitalOcean Managed Databases Guide

DigitalOcean Managed Databases

DigitalOcean Managed Databases provide fully managed database clusters for PostgreSQL, MySQL, Redis, MongoDB, and Apache Kafka. The service handles provisioning, patching, backups, failover, and scaling so you can focus on your application rather than database administration. Every managed database cluster runs on dedicated resources with SSD storage, is deployed in your VPC for network isolation, and includes automated daily backups with point-in-time recovery.

Managed Databases are available in multiple sizes from small development instances to large production clusters with standby nodes, read replicas, and connection pooling. This guide covers each supported engine, cluster configuration, security, backup and recovery, connection management, and operational best practices.

Supported Database Engines

PostgreSQL

DigitalOcean supports PostgreSQL versions 13 through 16, with automatic minor version upgrades. PostgreSQL is the most popular choice on the platform, offering advanced features like JSONB, full-text search, PostGIS for geospatial data, logical replication, and extensive extension support. The managed service includes connection pooling via PgBouncer, read replicas, and automatic failover with standby nodes.

# Create a PostgreSQL cluster
doctl databases create prod-pg \
  --engine pg \
  --version 16 \
  --region nyc3 \
  --size db-s-2vcpu-4gb \
  --num-nodes 3 \
  --private-network-uuid <vpc-uuid>

# Get connection details
doctl databases connection prod-pg-id

# Connection string format:
# postgresql://doadmin:password@host:25060/defaultdb?sslmode=require

MySQL

MySQL 8.x is supported with InnoDB as the default storage engine. The managed service handles binary log management for replication, automatic failover, and configurable SQL modes. MySQL on DigitalOcean uses SSL connections by default and supports read replicas for read-heavy workloads.

Redis

Redis 7.x is available as a managed service with persistence enabled by default. Redis clusters support configurable eviction policies (noeviction, allkeys-lru, volatile-lru, etc.) for cache vs. data store use cases. Managed Redis includes automatic failover with standby nodes and password-based authentication.

# Create a Redis cluster
doctl databases create prod-redis \
  --engine redis \
  --version 7 \
  --region nyc3 \
  --size db-s-1vcpu-2gb \
  --num-nodes 2

# Set eviction policy
doctl databases configuration update <db-id> \
  --engine redis \
  --config-json '{"redis_maxmemory_policy": "allkeys-lru"}'

MongoDB

MongoDB 6.x and 7.x are supported with replica sets for high availability. The managed service handles oplog management, automatic failover, and provides a connection string compatible with the MongoDB connection string URI format. MongoDB clusters include automated backups and support configurable read preferences.

Apache Kafka

DigitalOcean offers managed Apache Kafka for event streaming and messaging workloads. Kafka clusters include configurable topic retention, replication factors, and partition counts. The service handles broker management, ZooKeeper coordination (transparent to users), and provides SASL/SCRAM authentication with SSL encryption.

Cluster Sizing

Database clusters are available in sizes that match Droplet sizes, from small development instances to production-grade configurations. Each size specifies CPU, RAM, and storage. Storage is SSD-based and cannot be configured independently from the cluster size.

Database Sizes (PostgreSQL/MySQL):
  db-s-1vcpu-1gb    - 1 vCPU, 1 GB RAM, 10 GB disk   - $15/mo per node
  db-s-1vcpu-2gb    - 1 vCPU, 2 GB RAM, 25 GB disk   - $30/mo per node
  db-s-2vcpu-4gb    - 2 vCPU, 4 GB RAM, 38 GB disk   - $60/mo per node
  db-s-4vcpu-8gb    - 4 vCPU, 8 GB RAM, 115 GB disk  - $120/mo per node
  db-s-8vcpu-16gb   - 8 vCPU, 16 GB RAM, 270 GB disk - $240/mo per node
  db-s-16vcpu-64gb  - 16 vCPU, 64 GB RAM, 580 GB disk - $960/mo per node

Redis Sizes:
  db-s-1vcpu-1gb    - 1 vCPU, 1 GB RAM  - $15/mo per node
  db-s-1vcpu-2gb    - 1 vCPU, 2 GB RAM  - $30/mo per node
  db-s-2vcpu-4gb    - 2 vCPU, 4 GB RAM  - $60/mo per node

High Availability

For production workloads, deploy database clusters with standby nodes. A 3-node PostgreSQL or MySQL cluster consists of one primary and two standby nodes. The primary handles all writes and reads, while standby nodes maintain synchronous replication. If the primary fails, one standby is automatically promoted within approximately 15-30 seconds. The failover is transparent to your application because the connection hostname does not change.

Read Replicas

Read replicas are asynchronous copies of your database that can serve read queries, distributing read load across multiple nodes. They are ideal for read-heavy workloads, reporting queries, and analytics that would otherwise impact primary database performance. Read replicas can also be deployed in different regions for lower-latency reads.

# Create a read replica
doctl databases replica create <db-id> \
  --name prod-pg-replica-01 \
  --region sfo3 \
  --size db-s-2vcpu-4gb

# List replicas
doctl databases replica list <db-id>

# Get replica connection details
doctl databases replica connection <db-id> <replica-name>

Connection Pooling

PostgreSQL managed databases include built-in PgBouncer connection pooling. Connection pools sit between your application and the database, multiplexing many application connections over fewer database connections. This is critical for applications with many short-lived connections (serverless functions, microservices) because PostgreSQL has a per-connection memory overhead of approximately 10 MB.

# Create a connection pool
doctl databases pool create <db-id> \
  --name app-pool \
  --mode transaction \
  --size 20 \
  --db app_production \
  --user app_user

# Pool modes:
# transaction - connection returned after each transaction (recommended)
# session     - connection held for entire client session
# statement   - connection returned after each statement (limited compatibility)

Security

Trusted Sources

By default, managed databases restrict connections to known sources. You can configure trusted sources to allow connections from specific Droplets, Kubernetes clusters, App Platform apps, or IP addresses. This is enforced at the network level, providing an additional security layer beyond database authentication.

# Add trusted sources
doctl databases firewalls append <db-id> \
  --rule db_type:droplet,value:<droplet-id>

doctl databases firewalls append <db-id> \
  --rule db_type:k8s,value:<cluster-uuid>

doctl databases firewalls append <db-id> \
  --rule db_type:app,value:<app-id>

doctl databases firewalls append <db-id> \
  --rule db_type:ip_addr,value:203.0.113.50

# List firewall rules
doctl databases firewalls list <db-id>

SSL/TLS Encryption

All managed database connections require SSL/TLS encryption by default. The CA certificate is available from the control panel or API. Applications must connect using sslmode=require (PostgreSQL) or equivalent settings for other engines. This ensures all data in transit is encrypted between your application and the database, even within the VPC.

Backups and Recovery

DigitalOcean automatically creates daily backups of your managed database and retains them for 7 days. For PostgreSQL and MySQL, Write-Ahead Log (WAL) archiving enables point-in-time recovery to any second within the backup retention window. Backups are stored in a separate storage system from your database and are not affected by database node failures.

# List backups
doctl databases backups list <db-id>

# Restore to a point in time (creates a new cluster)
doctl databases create restored-db \
  --engine pg \
  --version 16 \
  --region nyc3 \
  --size db-s-2vcpu-4gb \
  --num-nodes 2 \
  --restore-from <db-id> \
  --restore-to "2026-03-14T02:30:00Z"

Maintenance Windows

DigitalOcean applies minor version updates and security patches during a configurable maintenance window. Set the window to a low-traffic period for your application. During maintenance, standby nodes are updated first, then a failover occurs to promote an updated standby, and finally the old primary is updated. This process causes a brief interruption (typically 10-30 seconds) during the failover step.

# Set maintenance window
doctl databases maintenance-window update <db-id> \
  --day sunday \
  --hour 04:00

Migration Strategies

To migrate an existing database to DigitalOcean Managed Databases, use native database tools for the most reliable migration. For PostgreSQL, use pg_dump and pg_restore or logical replication for zero-downtime migrations. For MySQL, use mysqldump or mysqlsh utilities. Plan for a testing phase on the managed cluster before cutting over production traffic.

Production Best Practices

• Use 3-node clusters for production workloads to ensure high availability with a standby after failover.
• Enable connection pooling for PostgreSQL to manage connection overhead efficiently.
• Configure trusted sources to restrict database access to only authorized applications and IPs.
• Set maintenance windows during low-traffic periods and monitor for failover events.
• Deploy read replicas for read-heavy workloads to offload the primary node.
• Monitor database metrics (connections, query latency, replication lag) through the control panel or Prometheus.
• Right-size your cluster based on actual CPU and memory usage, not just storage requirements.
• Test backups regularly by restoring to a temporary cluster and validating data integrity.