Pick the engine the application already speaks
The database plans on Broadbent Host can run MySQL, MariaDB, PostgreSQL, MongoDB or SQL Server 2022 Standard. You choose the engine when you customise. The plan size, the backup retention and the high-availability option do not change the dialect. A PostgreSQL application will not start because the server is a well-run MariaDB. A MariaDB import is not a PostgreSQL dump. This guide is the choice of engine, and of the plan around it. The longer tour of the plans is MariaDB and PostgreSQL hosting.
Read the application's documentation before you read our plan names. If it says PostgreSQL, order PostgreSQL. If it says MariaDB, order MariaDB. If it says MySQL, order MySQL, even though MariaDB is available and often close. If it says MongoDB, order MongoDB. If it says SQL Server, order SQL Server 2022 Standard. "Other" is a conversation for an enterprise order, not a guess you type into a connection string.
MariaDB or MySQL
Choose MariaDB when the vendor, the host you are leaving, or the client libraries name MariaDB, and when you want the managed instance Kubernetes refers to as the hosted MariaDB. A scaler on managed Kubernetes may call a service in the same namespace, the hosted MariaDB, or a public host. It may not call a private address in another namespace. That is a concrete reason to put MariaDB on this product rather than on an unlisted private server.
Choose MySQL when the vendor names MySQL and you do not want to discover a difference during import. The engines share a family. They are separate options in the configurator. Test a restore onto the engine you will run. Do not test it onto the other one and call that a rehearsal. Adminer, in the Compute app library, can look at MariaDB, MySQL, PostgreSQL or SQLite in a browser. It is a client. It is not the managed database and it is not the backup.
A small WordPress site can keep its database inside Plesk shared hosting. Move that database onto a managed plan when you need a dedicated address, a stated retention, or a replica. WordPress is usually MySQL or MariaDB. Check which one the site was using before you pick.
PostgreSQL
Choose PostgreSQL when the application, the extensions and the dump tools are PostgreSQL. It uses the same plan ladder: Starter at £29.99 with 20 GB and 2 GB of RAM, Standard at £39.99 with 50 GB and 4 GB, Business at £59.99 with 100 GB and 8 GB, Enterprise at £149.99 with 250 GB, a 16-core dedicated CPU and 32 GB of dedicated RAM. Those monthly figures are the plan cards. Options change the checkout total. Yearly figures are on the same cards.
PostgreSQL does not share files with a MariaDB instance. Two engines means two databases. An application that wants both gets two connection strings and two backup conversations. SSL, IP restrictions and automatic security patches apply to the plan, not only to one engine. Enterprise adds VPN access and encryption at rest. Those are Enterprise features, not PostgreSQL features.
MongoDB or SQL Server
Choose MongoDB when the data is documents and the driver is a MongoDB driver. Do not choose MariaDB because the plan page was easier to read. Choose SQL Server 2022 Standard when the application is SQL Server. The same backup and address rules apply. The skill required to restore does not. A SQL Server restore is not a mysqldump, and a MongoDB restore is not a pg_dump. Name the tool in the runbook when you name the engine.
If you are unsure, stop and match the engine to a system you already run in production. A new build can pick PostgreSQL or MariaDB for its own reasons, and those reasons should be written down by the people who will operate it. The hosting plan will not supply the reason.
Then pick the plan, not a second engine
Starter, Standard and Business include daily backups kept for 7 days. Extra retention is £5 per month for each extra week, in 7-day steps, up to 28 days. Enterprise includes hourly backups kept for 28 days, and includes the multi-node cluster with a shared virtual IP. On the smaller plans, high availability is optional: a pair with a replica and automatic failover, or a three-node synchronous cluster. Failover keeps the shared virtual IP. A single instance has one dedicated IP and no replica.
Buy the replica when a node failure must not change the address and must not wait for a restore. Buy the longer backup window when a bad change might be noticed after a week. Buy both when you need both. A replica will copy a dropped table. A backup is what puts the table back. High availability is not retention, and retention is not a second site unless the plan says so. These plans are on the Colchester cluster.
The firewall choice is the same on every engine. No extra firewall, the managed cluster firewall where you add rules, or a dedicated self-managed Cisco appliance. Restrict the IP to the application. A database open to the world is not made safe by the engine name.
Where the client runs
The client can be a site on Plesk, a process on a virtual server, or a pod in a namespace. The database sees an address, a credential and an allowed IP. Put the credential in the place that application already uses for secrets. Do not bake it into an image. Scaling the pods with KEDA does not scale the database RAM. A larger database is a plan change. The FAQ says most storage, RAM and CPU changes can be done with little or no downtime. A restore cannot. Plan the restore as its own change.
Migration from another provider is available. It needs a rehearsal. Cut over when the rehearsal matches. Keep the old instance until you have looked for a missing table. Connection details for the new instance arrive by email after provisioning.
A short way to decide
Write the engine name from the application. Write the disk you have and the disk you will have, and match 20, 50, 100 or 250 GB. Write how many days back you must restore, and add weeks or use Enterprise. Write whether a node failure may change the address. If it may not, add high availability or use Enterprise. Write who connects, and pick the firewall tier. Then order database hosting. The topic Managed database hosting repeats the service as a landing page if you need to send one URL to someone who will not read this choice in order.
If you cannot write the engine name, you are not ready to order. Ask the person who built the application. Ordering MariaDB for a PostgreSQL code base spends the migration window on the wrong dialect, and the backup you then take is a backup of a database the application cannot use.
Sizes, written as a choice
Starter is £29.99 a month, 20 GB of storage and 2 GB of RAM, for development, staging and smaller production databases. Standard is £39.99, 50 GB and 4 GB, for production that needs more headroom. Business is £59.99, 100 GB and 8 GB. Enterprise is £149.99, 250 GB, a 16-core dedicated CPU and 32 GB of dedicated RAM. All four are multi-core on the smaller cards and dedicated at Enterprise. All four let you choose the engine. A larger disk does not change MariaDB into PostgreSQL. Match the disk to the data you have, plus indexes and the logs the engine keeps, not to a round number that sounds safe. 20 GB is easy to pass once a busy log is included. Moving up the ladder is the scaling path, and the FAQ says most storage, RAM and CPU changes can be done with little or no downtime.
Daily backups for 7 days come with Starter, Standard and Business. Each extra week is £5 a month, up to 28 days. Enterprise is hourly, kept 28 days, and already includes the multi-node cluster. Add the pair, replica plus automatic failover, or the three-node synchronous cluster, on the smaller plans when the address must survive a node. The address on those options is a shared virtual IP. A single instance has one dedicated IP. Write down which address you were sent. A later failover is not supposed to change it. A restore of a dropped table is a different event and uses the backup, not the replica, because the replica will have the drop.
Connection, firewall, and Kubernetes
Details arrive by email. You connect with a normal client or with the application. SSL and IP restrictions apply. Enterprise adds VPN access and encryption at rest. The firewall tier is chosen per plan: none beyond that, the managed cluster firewall with rules you add, or a dedicated self-managed Cisco appliance. The Cisco ASA and Firepower plans on the firewall page are the rack devices. They are not added to Starter because the database is MariaDB.
If the application is in a namespace, the hosted MariaDB is an allowed KEDA host, and a public host is allowed. A private address in another namespace is not. The application still uses the connection string. Scaling replicas from 0 to 20 does not enlarge the database plan. If the database is the bottleneck, change the plan. If the application is the bottleneck, change the replicas. Those are different bills: the database card on one side, the Kubernetes request and burst on the other.
A rehearsal before the cut-over
Take a copy from the current engine with that engine's tools. Restore it onto the same engine on the new plan. Point a staging copy of the application at the new address and run the checks the application already has. Then plan the cut-over. Keep the old instance until production has been read, not only written, on the new one. Migration help is available and aims at little downtime. It does not remove the need for the rehearsal. A MongoDB backup restored onto SQL Server is not a rehearsal. A MySQL dump restored onto PostgreSQL is not one either.
Shared hosting remains reasonable for a small site database that lives with the site in Plesk. A virtual server remains reasonable when you want to install and patch the engine yourself and you have the root access of a self-managed plan. This product is the one to order when the engine, the address, the retention and the optional replica should be the things on the invoice, and the cluster they run on is in Colchester. Order it when you can say the engine out loud. The landing page is there if you need a single link. The plan page is there when you are ready to configure the options.
After you have chosen
Send the connection string only to the application and to the people who administer it. Restrict the IP. Run the application's migrations against a restored copy, not against a guess. Note the retention you bought, in days, in the same place you keep the address. Note whether that address is a dedicated IP or a shared virtual IP. On the first day, confirm a backup exists even if you do not restore it yet. On the first week, look at disk used against 20, 50, 100 or 250 GB, whichever you ordered.
If the client is Kubernetes, keep the database password out of the image. If the client is Plesk, do not also leave an abandoned copy of the same database inside the shared account, or you will edit the wrong one. If the client is a virtual server you manage, the managed database is still the system of record and the server is only the client. One writer. One engine. One address. That is the whole decision, once the engine name was taken from the application rather than from a preference for a particular word.
Write the engine, the plan size and the retention in the same note as the address, and keep that note with the application rather than in a chat log.