Managed Databases

Running your own database on a CloudSonic server is fast and straightforward, but there are situations where you'd rather not think about it at all. That's what Managed Databases are for.

With a Managed Database, CloudSonic handles provisioning, tuning, backups, failover, and version upgrades. You get a connection string and you connect to it. Nothing else to do.

What's included

Every Managed Database comes with:

• 3-node replication -- one primary node handles writes, two replicas handle reads and serve as automatic failover targets
• Automatic failover -- if the primary goes down, a replica is promoted in under 30 seconds with no action needed from you
• Daily backups retained for 7 days, with point-in-time recovery available on Pro plans
• Automatic minor version upgrades -- security patches applied automatically during your maintenance window
• Private networking -- your CloudSonic servers connect to managed databases over private IP, never the public internet
• Connection pooling built in -- no need to manage PgBouncer or ProxySQL yourself
• Metrics and alerting -- query performance, connection counts, replication lag, and disk usage all visible in the dashboard

Available databases

Replication architecture

                    Write
                      |
              [Primary Node]
             /              \
    [Replica 1]          [Replica 2]
   (synchronous)        (synchronous)

Both replicas use synchronous replication -- a write is not acknowledged until at least one replica has confirmed it. This means no data loss on failover, even if the primary dies mid-transaction.

Read replicas are available as separate connection endpoints if your application wants to send SELECT queries to a replica and free up the primary for writes.

Supported cloud providers

Managed Databases can be deployed on the same cloud provider as your CloudSonic servers, keeping traffic on the private network:

• DigitalOcean
• Vultr
• Hetzner
• AWS
• Google Cloud Platform
• Linode / Akamai

Connecting to a managed database

Once provisioned, your connection details are available in the CloudSonic dashboard. They look like this for PostgreSQL:

# Private network (recommended -- use this when your app is on CloudSonic)
postgresql://myapp_user:password@private-db-01.cloudsonic.internal:5432/myapp

# Public endpoint (for connecting from your local machine)
postgresql://myapp_user:password@db-01-sydney.cloudsonic.com:5432/myapp

For MariaDB:

# Private network
mysql://myapp_user:password@private-db-01.cloudsonic.internal:3306/myapp

# Public endpoint
mysql://myapp_user:password@db-01-sydney.cloudsonic.com:3306/myapp

Connecting from your app server

On a CloudSonic application server, use the private hostname. No TLS configuration needed on the private network.

PHP / WordPress:

define('DB_HOST', 'private-db-01.cloudsonic.internal');
define('DB_NAME', 'mywordpresssite');
define('DB_USER', 'wp_user');
define('DB_PASSWORD', 'your-password');

Node.js (PostgreSQL with pg):

const { Pool } = require('pg');

const pool = new Pool({
    connectionString: process.env.DATABASE_URL,
    max: 20,
    idleTimeoutMillis: 30000,
    connectionTimeoutMillis: 2000,
});

Laravel (.env):

DB_CONNECTION=pgsql
DB_HOST=private-db-01.cloudsonic.internal
DB_PORT=5432
DB_DATABASE=myapp
DB_USERNAME=myapp_user
DB_PASSWORD=your-password

Sizing guide

Managed Database plans are sized by vCPUs, RAM, and storage. As a rough guide:

Storage scales independently from compute. Start with what you need and expand with no downtime.

Migrating from a self-managed database

If you're running your own database on a CloudSonic server and want to move to a Managed Database, the process is straightforward.

PostgreSQL:

# Dump from your current server
PGPASSWORD=$(cat /etc/postgresql/superuser.conf) \
  pg_dump -U postgres -h 127.0.0.1 -p 5433 -Fc myapp > myapp.dump

# Restore to the managed database
pg_restore \
  -d "postgresql://myapp_user:password@db-01-sydney.cloudsonic.com:5432/myapp" \
  myapp.dump

MariaDB:

# Dump from your current server
mysqldump -u root -p$(sudo cat /etc/mariadb/root.conf) myapp | gzip > myapp.sql.gz

# Restore to the managed database
gunzip -c myapp.sql.gz | mysql \
  -h db-01-sydney.cloudsonic.com \
  -u myapp_user \
  -p myapp

After the restore, update your application's database connection string and deploy. Downtime is typically a few seconds for the DNS change to propagate.