Migrate from DigitalOcean Managed Databases to DanubeData

This guide shows how to plan and rehearse a migration from DigitalOcean managed databases to DanubeData. Compare current quotes for equivalent memory, storage, backups, recovery, replicas and availability before deciding whether a move reduces your total cost.

Why Teams Are Leaving DigitalOcean

We've helped dozens of teams migrate from DigitalOcean. Here are the most common reasons:

1. Pricing Has Increased

DigitalOcean used to be the budget-friendly option. Not anymore. Their managed database pricing now rivals AWS in many cases, without the feature parity.

2. Data Residency Concerns

For European companies, GDPR compliance requires careful consideration of where data is processed. DigitalOcean's Frankfurt datacenter is an option, but their parent company is US-based, which creates CLOUD Act concerns for some organizations.

3. Limited Feature Set

DigitalOcean's managed databases lack features like read replica auto-scaling, detailed query analytics, and comprehensive backup options that other providers offer.

4. Support Limitations

Business-critical database issues require premium support plans that add significant cost.

Cost Comparison: DigitalOcean vs DanubeData

Let's compare actual pricing for equivalent database configurations:

Compare Database Configurations Before Migrating

As checked on 2 November 2026, the following DanubeData database plans have distinct capacities. Prices are monthly equivalents, billed hourly and excluding VAT. They are not a matched DigitalOcean quote.

A source with 25 GB of allocated storage does not match the 20 GB base DD Uzlina plan. Confirm used space, growth headroom and the configured storage quote before migration. Check engine/version availability and the selected backup and recovery options in the PostgreSQL or MySQL configurator. For Redis, compare a current cache configuration; do not substitute a smaller memory tier just to lower the price.

Obtain a current DigitalOcean managed-database quote for the actual region and topology. Convert both quotes using one dated exchange rate and include tax, transfer, backups, replicas and standby nodes. A read replica is not a promise of an equivalent HA standby or failover topology.

Feature Comparison

Migration Overview

The migration process varies by database type. We'll cover:

1. PostgreSQL migration (pg_dump/pg_restore or logical replication)
2. MySQL migration (mysqldump or replication)
3. Redis migration (RDB export or MIGRATE command)

Choose your approach based on:

• Database size: Small databases (<10GB) can use dump/restore
• Downtime tolerance: Zero-downtime requires replication
• Complexity preference: Dump/restore is simpler but requires maintenance window

PostgreSQL Migration

Option 1: pg_dump/pg_restore (Simple, With Downtime)

Best for databases under 50GB or when a maintenance window is acceptable.

Step 1: Create DanubeData PostgreSQL Instance

1. Log into DanubeData dashboard
2. Navigate to Databases → Create Database
3. Select PostgreSQL and choose your plan
4. Note the connection details

Step 2: Prepare Source Database

# Get your DigitalOcean connection details from their dashboard
# Format: postgresql://user:password@host:port/database?sslmode=require

# Test connection
psql "postgresql://doadmin:password@db-postgresql-fra1-12345-do-user-12345678-0.b.db.ondigitalocean.com:25060/defaultdb?sslmode=require"

Step 3: Create Backup

# Full database dump with custom format (recommended)
pg_dump 
  "postgresql://doadmin:YOUR_PASSWORD@your-do-host:25060/your_database?sslmode=require" 
  -Fc 
  -v 
  -f backup.dump

# Check dump size
ls -lh backup.dump

Step 4: Configure Target Firewall

In DanubeData dashboard, add your current IP to the database firewall rules.

Step 5: Restore to DanubeData

# Restore to DanubeData
pg_restore 
  -h your-db.danubedata.ro 
  -U your_user 
  -d your_database 
  -v 
  --no-owner 
  --no-acl 
  backup.dump

# Enter password when prompted

Step 6: Verify Data

# Connect to DanubeData
psql -h your-db.danubedata.ro -U your_user -d your_database

# Check tables
dt

# Verify row counts
SELECT schemaname, relname, n_live_tup
FROM pg_stat_user_tables
ORDER BY n_live_tup DESC;

Option 2: Logical Replication (Zero Downtime)

For larger databases or when you can't afford downtime.

Step 1: Enable Logical Replication on Source

DigitalOcean managed databases don't support logical replication out of the box. Contact their support to enable it, or use the dump/restore method.

If you have a self-managed PostgreSQL on a DigitalOcean Droplet:

# postgresql.conf
wal_level = logical
max_replication_slots = 4
max_wal_senders = 4

# Restart PostgreSQL
sudo systemctl restart postgresql

Step 2: Create Publication on Source

# On source database
CREATE PUBLICATION migration_pub FOR ALL TABLES;

Step 3: Create Schema on Target

# Dump schema only from source
pg_dump 
  "postgresql://user:pass@source:25060/db?sslmode=require" 
  --schema-only 
  -f schema.sql

# Apply to target
psql -h your-db.danubedata.ro -U your_user -d your_database -f schema.sql

Step 4: Create Subscription on Target

# On DanubeData database
CREATE SUBSCRIPTION migration_sub
CONNECTION 'host=source-host port=25060 dbname=source_db user=repl_user password=repl_pass sslmode=require'
PUBLICATION migration_pub;

Step 5: Monitor Replication

# Check subscription status
SELECT * FROM pg_stat_subscription;

# Check replication lag
SELECT
    slot_name,
    confirmed_flush_lsn,
    pg_current_wal_lsn(),
    pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag
FROM pg_replication_slots;

Step 6: Cutover

# When lag is zero:
# 1. Stop writes to source application
# 2. Verify final sync
# 3. Update application connection strings
# 4. Start application with new connection
# 5. Drop subscription when confirmed

DROP SUBSCRIPTION migration_sub;

MySQL Migration

Option 1: mysqldump (Simple, With Downtime)

Step 1: Create DanubeData MySQL Instance

1. Log into DanubeData dashboard
2. Navigate to Databases → Create Database
3. Select MySQL and choose your plan
4. Note the connection details

Step 2: Export from DigitalOcean

# Full database dump
mysqldump 
  -h your-do-host.db.ondigitalocean.com 
  -P 25060 
  -u doadmin 
  -p 
  --ssl-mode=REQUIRED 
  --single-transaction 
  --routines 
  --triggers 
  --set-gtid-purged=OFF 
  your_database > backup.sql

# Compress for faster transfer
gzip backup.sql

Step 3: Import to DanubeData

# Decompress
gunzip backup.sql.gz

# Import to DanubeData
mysql 
  -h your-db.danubedata.ro 
  -u your_user 
  -p 
  --ssl-mode=REQUIRED 
  your_database < backup.sql

Step 4: Verify

# Connect to DanubeData
mysql -h your-db.danubedata.ro -u your_user -p your_database

# Check tables
SHOW TABLES;

# Verify row counts
SELECT
    TABLE_NAME,
    TABLE_ROWS
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_database'
ORDER BY TABLE_ROWS DESC;

Option 2: MySQL Replication (Zero Downtime)

DigitalOcean managed MySQL doesn't support external replication. For zero-downtime migration from managed MySQL, consider:

1. Using a tool like pt-online-schema-change for large tables
2. Application-level dual-write during migration
3. Scheduling a brief maintenance window during low traffic

Redis Migration

Option 1: RDB Export/Import

DigitalOcean doesn't expose RDB files directly. Use the MIGRATE command or dump/restore approach:

Step 1: Create DanubeData Redis Instance

1. Log into DanubeData dashboard
2. Navigate to Cache → Create Cache Instance
3. Select Redis and choose your plan

Step 2: Export Keys Using redis-dump

# Install redis-dump (requires Ruby)
gem install redis-dump

# Export all keys
redis-dump 
  -u redis://default:PASSWORD@your-do-redis:25061 
  --tls > redis-backup.json

Step 3: Import to DanubeData

# Import using redis-load
cat redis-backup.json | redis-load 
  -u redis://default:PASSWORD@your-cache.danubedata.ro:6379

Option 2: MIGRATE Command (For Small Datasets)

# For each key or pattern
redis-cli -h source-host -p 25061 --tls -a PASSWORD 
  MIGRATE target-host 6379 "" 0 5000 COPY REPLACE AUTH PASSWORD KEYS key1 key2 key3

Option 3: Application-Level Migration

For cache data, the simplest approach is often:

1. Deploy application pointing to new Redis
2. Let cache warm up naturally
3. Old cache data expires on its own

This works well for session data and computed caches that will repopulate automatically.

Application Connection Update

Update Environment Variables

# Before (DigitalOcean)
DATABASE_URL=postgresql://doadmin:PASSWORD@db-postgresql-fra1-12345.db.ondigitalocean.com:25060/defaultdb?sslmode=require
REDIS_URL=rediss://default:PASSWORD@db-redis-fra1-12345.db.ondigitalocean.com:25061

# After (DanubeData)
DATABASE_URL=postgresql://your_user:PASSWORD@your-db.danubedata.ro:5432/your_database?sslmode=require
REDIS_URL=redis://default:PASSWORD@your-cache.danubedata.ro:6379

For Laravel Applications

# .env
DB_CONNECTION=pgsql
DB_HOST=your-db.danubedata.ro
DB_PORT=5432
DB_DATABASE=your_database
DB_USERNAME=your_user
DB_PASSWORD=your_password

REDIS_HOST=your-cache.danubedata.ro
REDIS_PASSWORD=your_redis_password
REDIS_PORT=6379

For Node.js Applications

// database.js
const { Pool } = require('pg');

const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  ssl: {
    rejectUnauthorized: true
  }
});

module.exports = pool;

DNS Cutover Strategy

For seamless migration without changing application code:

Step 1: Lower TTL (1 Week Before)

# Reduce TTL to 60 seconds
db.yourdomain.com.    60    IN    CNAME    db-postgresql-fra1-12345.db.ondigitalocean.com.

Step 2: Update DNS Record

# Point to DanubeData
db.yourdomain.com.    60    IN    CNAME    your-db.danubedata.ro.

Step 3: Verify Propagation

dig db.yourdomain.com +short

Step 4: Restore TTL

# After confirming everything works
db.yourdomain.com.    3600    IN    CNAME    your-db.danubedata.ro.

Post-Migration Checklist

Rollback Plan

Always have a rollback plan. Keep your DigitalOcean database running for at least 48 hours after migration:

If Issues Occur

1. Update application to point back to DigitalOcean
2. If DNS-based: revert DNS records
3. Investigate the issue
4. Plan for re-migration

DigitalOcean Cleanup

After confirming successful migration (recommended: wait 1 week):

1. Take a final backup of DigitalOcean database (for archive)
2. Destroy the managed database cluster
3. Remove any related firewall rules

Troubleshooting

Connection Refused

# Check firewall rules in DanubeData dashboard
# Add your application server's IP address

# Verify connectivity
telnet your-db.danubedata.ro 5432

SSL Certificate Issues

# Force SSL in connection string
?sslmode=require

# For Node.js with self-signed certs (if needed)
ssl: { rejectUnauthorized: false }

Permission Denied

# Check user privileges
du

# Grant necessary permissions
GRANT ALL PRIVILEGES ON DATABASE your_database TO your_user;
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO your_user;

Encoding Issues

# Check database encoding
SELECT pg_encoding_to_char(encoding) FROM pg_database WHERE datname = 'your_database';

# Ensure UTF-8 is used consistently

Summary: Migration Timeline

Ready to Migrate?

Rehearse the migration with production-like data and measure the cutover window. Cost and downtime depend on the selected configurations, data size, replication support and validation work; neither a fixed saving nor zero downtime is guaranteed.

? Create your free DanubeData account

Then provision your databases and follow this guide. Our support team is available if you run into any issues during migration.

What you'll get:

• Compare reliability, recovery requirements and the full configured price
• ✅ European data residency (Germany)
• ✅ Priority support included at no extra cost
• ✅ More cache options (Redis, Valkey, Dragonfly)
• ✅ Detailed monitoring and metrics

Need help with your migration? Contact our team—we've migrated dozens of databases from DigitalOcean and can guide you through the process.

Continue with a practical guide

• How to Migrate from AWS RDS to DanubeData (Step-by-Step Guide)
• Back Up PostgreSQL to S3: pg_dump vs pgBackRest (2026)
• Database Connection Pooling Explained: When and Why You Need It