Managed databases

1. Engines

Redis is not offered. The stack can run it, but it has no named databases or users, no logical dump — so no backup, restore or import — and no parameter groups. Offering it beside engines where all of that works would be selling a different product under the same name.

2. Creating a cluster

Databases → Create Cluster.

1. 1Name the cluster.
2. 2Engine and version.
3. 3Plan and region — the same picker as Create Server: RAM slider, recommended plans, "See all matching plans", and a region chooser. These are ordinary VPS plans, because that is what the cluster runs on.
4. 4Allowed IP addresses (optional) — see Access. Leave it empty and the database port is open to everyone, which the form says plainly.
5. 5Terms and conditions, then Create Cluster.

What happens next

The page turns into an installation log, the same as the server installer:

Ordering a s-1vcpu-1gb VPS in Bangalore 1…
VPS 591807021 is up at 168.144.88.95, VPC address 10.122.0.3
Waiting for SSH to accept connections…
Installing Docker and starting the database…
Waiting for the database to accept connections…

Typically 3–6 minutes. The cluster record is created before the VPS is ordered, so if anything fails you still see the cluster, the reason, and the id of any server that was bought — nothing is left running that you cannot see.

Billing

Billing follows the host provider, exactly as Create Server does: DigitalOcean bills hourly through the monthly invoice; Contabo and OVH are prepaid and collect before provisioning. The price is frozen when you order, so the estimate and the invoice can never disagree.

Clusters appear on Billing → Overview under Managed Databases, and stay there for the days they ran even after deletion.

3. The cluster list

Each cluster is a card: name, status, vCPU/RAM/storage/region/nodes, engine and version, plan, creation date, price, and the databases inside it.

Manage offers:

4. Overview tab

Status, configuration, and CPU / RAM / disk graphs over a selectable window — the same treatment as a server's Overview.

5. Connection tab

Everything needed to connect:

• Public and VPC host and port — toggle between them
• Connection string, in a format dropdown, with show-password and copy
• User and database selectors
• Download CA certificate once encryption is on

Use the VPC address from another server in the same region: it does not leave the private network and is not subject to the public firewall.

6. Databases tab

Lists the databases in the cluster. New database creates the database and a user for it, and shows the credentials once — they are also kept on the database's own page, so you do not have to copy them under pressure.

Click a database to open it.

Database → Overview

Name, host, port, its own user, SSL state, its parameter group, and a connection string built from that database's credentials.

Database → Access

• Database Credentials — database name, user selector, password with copy, and a pencil that generates a new one (shown once).
• Launch Adminer — installs a web client on the cluster's host on demand and signs you in automatically. PostgreSQL and MySQL only.
• Import / Export — see below.
• Users with access — grant and revoke per database.

Import and export

Export downloads a fresh gzipped dump. It is a download, not a backup: it does not appear in the Backups tab, count against retention, or cost storage.

Import replaces the database's contents from a dump you upload (.sql.gz, .sql, or .archive for MongoDB; .zip is not supported yet).

Before anything is touched, the file is checked:

• Engine match. A MySQL dump uploaded to a PostgreSQL cluster is refused outright, rather than failing halfway through with a syntax error.
• Format. A file named .gz that is not gzip is refused.

Then, in order: a safety backup is taken; missing roles the dump references are created (a dump from another server is full of OWNER TO postgres, and that role does not exist here); the database is dropped and recreated; the dump is loaded; and ownership of everything imported is moved to the cluster's user so your credentials can read it.

If the safety backup fails, the import does not start.

7. Users tab

Cluster-wide users. Users created here can reach every database; users created alongside a database are scoped to it.

8. Logs & Queries tab

• Engine log — what the database process itself printed, straight off the container, 100–2000 lines. This is the only place a startup failure appears; the query views below need a working database to ask.
• Running queries and query statistics, read live.

9. Configuration tab

Two sub-tabs.

Parameters

Every parameter the engine has, discovered from the running engine rather than a list we maintain — so it is correct for the version actually installed. For each:

Searchable, paginated, with Common only and Changed only filters. Edit a value and press Apply; static parameters restart the database, which is stated before you confirm.

Beneath the table is the file the values live in — postgresql.auto.conf or custom.cnf.

Parameter groups

A parameter group is a named set of parameters you can reuse. Groups belong to the cluster they were created on.

• Attached to this cluster — applies the group's server-level parameters (max_connections, shared_buffers).
• Per group, expand a row to see its parameters and tick which databases in this cluster it governs. The same group can hold different values for different databases where the engine allows it.

Two scopes, and they are not the same thing:

A per-database value beats the cluster-level one for that database. A group on the cluster setting work_mem = 4MB, and a different group on app1 setting 64MB, is not a conflict: app1 gets 64MB and everything else gets 4MB.

Assigning a group to a database changes only that database; its server-level entries are listed as not applied, and attaching the group to the cluster is the separate, deliberate step that applies those.

Manage groups across clusters from Databases → Parameter groups, where a group's own page lets you add and remove parameters and push it to every cluster using it.

10. Backups tab

Two tabs, because they are not equivalent protection:

• Local — dumps on the cluster's own VPS. Free, fast to restore from, and lost with the server.
• Offsite — additionally copied to object storage. Survives losing the server. Billed per GB and added to your monthly invoice; you are asked to confirm before enabling it.

Back up now takes a dump immediately, of one database or all of them.

Automatic Backup Schedule — None, Daily, Weekly, 14 Days or Monthly, plus how many to keep. Saving asks you to confirm and shows when the next backup runs. Backups are taken by an hourly sweep, so one due mid-hour runs at the next quarter past.

Restore — on any completed backup:

• Into a new database (the default) — leaves current data untouched so you can check the restore before switching over.
• Overwrite — behind a typed confirmation, and only after an automatic safety backup.

An offsite backup is fetched back automatically when restored.

11. Access tab

Who may reach the database port. Two independent allow-lists, OR'd together:

• IP addresses — single addresses or CIDR ranges.
• Countries — connections from addresses registered to those countries.

With both empty the port is open to everyone, which the tab says in red.

The tab shows what the host is actually enforcing, read off the box rather than what we believe we applied — the two disagreeing is the interesting case.

Country matching follows where an address block is registered, which a VPN or a relocated block can misrepresent. Use it to narrow exposure, not as the only control on sensitive data.

Rules apply to the web client's port too, so installing Adminer never quietly opens a way in that the database port refuses.

12. Settings tab

Encryption in transit — generates a certificate on the host and restarts the database with TLS required. Expect a few seconds' interruption. Afterwards, download the CA certificate from the Connection tab and point your client at it. PostgreSQL and MySQL only.

Power — two levels:

A powered-off server is still billed by the provider. Only deleting the cluster stops the cost.

Deletion protection — while on, delete is refused, including from the API.

Delete this cluster — destroys every database, every user, every backup (host and offsite), and the VPS. Type the cluster name to confirm. There is no undo.

13. Getting started, in order

1. 1Create the cluster. Wait for the installation log to finish.
2. 2Access tab — add your application server's IP. Do this first; a database open to the internet is the default until you do.
3. 3Databases tab — create a database and note its credentials.
4. 4Connection tab — copy the connection string. Use the VPC address if the client is in the same region.
5. 5Settings — turn on encryption, and deletion protection for anything you care about.
6. 6Backups tab — set a schedule, and decide on offsite.
7. 7Restore something once, into a new database, so you know the path works before you need it.

14. Known limits

• Single node. No automatic failover and no read replicas. A cluster is one VPS: if it is lost, only an offsite backup survives.
• No point-in-time recovery. Recovery is to the last backup, so a daily schedule means up to a day of loss.
• No engine version upgrades yet — the version is fixed at creation.
• MongoDB has no encryption in transit, no web client, and no per-database parameters.
• .zip dumps are not supported on import; gzip or upload the plain file.
• Provisioning is DigitalOcean only today.

15. When something goes wrong