MariaDB and PostgreSQL on Broadbent Host
Database hosting is a managed database on the Colchester cluster. You choose the engine when you customise the plan. The engines on the database FAQ are MySQL, MariaDB, PostgreSQL, MongoDB and SQL Server 2022 Standard. Other engines can be discussed for an enterprise order. This article is about the two people ask for by name most often, MariaDB and PostgreSQL, and about the plan around them. MySQL stays on the list because a lot of existing applications still say MySQL when the server that will actually run is MariaDB, or the other way round. Pick the name your application was built for.
The plans, the backup rules and the high-availability options are the same shape whichever of those engines you choose. The differences that matter are the ones on the plan card: storage, memory, whether high availability is included or added, and how often the backup runs. Connection details arrive by email after the database is provisioned. A single-instance plan has one dedicated IP. A high-availability plan has a shared virtual IP so the address stays the same when failover happens.
Prices below are the monthly figures on the plan cards. Starter is £29.99, Standard is £39.99, Business is £59.99 and Enterprise is £149.99. Yearly figures are on the same cards. Confirm the amount at checkout, including any option you add. This article does not add a second price on top of those cards.
The four plans
Starter is for development, staging and smaller production databases. It includes 20 GB of database storage, 2 GB of RAM and a multi-core CPU, one dedicated IP, daily backups kept for 7 days, optional high availability and 24/7 technical support. Standard is for production that needs more headroom: 50 GB and 4 GB of RAM, on the same pattern of address, backup and optional high availability. Business moves to 100 GB and 8 GB of RAM. Enterprise is 250 GB of storage, a 16-core dedicated CPU and 32 GB of dedicated RAM. Enterprise includes the multi-node high-availability cluster and a shared virtual IP, and its backups are hourly with 28-day retention.
Starter, Standard and Business can add retention at checkout in steps of 7 days, up to 28 days, at £5 per month for each extra week. Enterprise already includes 28 days. Do not buy the extra weeks on a plan that already keeps a month, and do not assume Starter keeps a month because Enterprise does.
High availability on Starter, Standard and Business is an option at checkout. You can add a pair, which is a replica plus automatic failover, or a three-node synchronous cluster. Failover uses the shared virtual IP so applications keep the same address. Enterprise includes the multi-node cluster by default. A single instance does not grow a replica because the disk filled up. The replica is the option you selected.
MariaDB
MariaDB is the engine to choose when the application, the import and the client libraries expect MariaDB or a MySQL-compatible server and you have decided MariaDB is the one we should run. It is also the engine named on the Kubernetes side: a KEDA trigger may use a service in the same namespace, the hosted MariaDB, or a public host. A private address in another namespace is refused. If a namespace scales from a queue or a table that lives on this database product, the hosted MariaDB is the allowed path. The application in the namespace still uses the connection details we send. It does not get a cluster-admin view of the database server.
Adminer, in the Compute app library, is a small browser tool that can manage MariaDB, MySQL, PostgreSQL or SQLite. It is an app you run. It is not a substitute for the managed database, and it is not how the backups are taken. Use it when a person needs to look at a schema from a browser. Use the managed plan when the data has to stay up, get backed up, and keep an address your application can rely on.
MySQL remains a separate choice on the same plans. If the vendor says MySQL, order MySQL. If the vendor says MariaDB, order MariaDB. They are close. They are not the same selection in the configurator. An import taken from one and restored to the other needs a test, not an assumption. The plan FAQ says we can help plan and run a migration from another provider, with the aim of little downtime. The test restore is part of that work. It is not optional if the application is already in production somewhere else.
PostgreSQL
PostgreSQL is the engine to choose when the application expects PostgreSQL: the client, the extensions you actually use, and the dump format. It sits on the same plans, with the same storage steps, the same backup retention rules and the same high-availability choice. It does not share a data directory with a MariaDB instance. If you need both, they are two databases, two choices, and two connection strings. Putting both engines on one casual shared-hosting account is a different product from this one. This product is a managed instance of the engine you picked.
Connection is ordinary. You receive the details by email. You connect with a normal client, the command line, or the application. SSL is used for connections. IP restrictions apply. There is no special Broadbent driver. If the application runs on Kubernetes, the host it is allowed to call is the hosted database or a public host, under the trigger rules, and the application itself uses the address we gave you. If the application runs on a virtual server or on shared hosting, it uses that same address. The database does not care which of our products the client runs on. It cares that the IP is allowed and the credentials are the ones issued for that instance.
A PostgreSQL dump is not a MariaDB dump. Take the backup from the engine you run, and rehearse the restore on that engine. The daily backups on Starter, Standard and Business, and the hourly backups on Enterprise, are the retention described above. They are not a logical dump you can assume is in a particular client format unless we have agreed that as part of a migration. Ask for the restore test when the database is the one the business cannot lose. The FAQ says most scaling of storage, RAM or CPU can be done with little or no downtime. A restore is not scaling. A restore is a planned event.
Backups, failover, and the address
Daily backups with 7-day retention are the default on Starter, Standard and Business. Extending that is £5 per month per extra week, in 7-day steps, up to 28 days. Hourly backups with 28 days are Enterprise. Retention is how far back you can go. It is not how fast we notice a bad deploy. A bad schema change that is discovered on day eight is outside a 7-day window. Buy the longer window if the business would need that day, or move to the plan that already keeps it.
The shared virtual IP is the point of the high-availability option. Applications keep the same address during failover. You do not rewrite configuration because a node changed. A single-instance plan has a dedicated IP and does not have that failover. If the application cannot tolerate the instance being on one machine, add the pair or the three-node cluster, or use Enterprise, which includes the multi-node cluster. Synchronous three-node is the cluster option. The pair is replica plus automatic failover. They are different checkouts. Read the option you are adding.
Failover does not repair a dropped table. It keeps the service on the address when a node fails. A dropped table is in the data, so the replica has the drop as well once replication has applied it. The backup is what you use for that. High availability and backups answer two different failures. Order both when you need both.
Security and the firewall options
Every plan can sit behind no extra firewall, behind our managed cluster firewall where you add your own rules, or behind a dedicated self-managed Cisco appliance. SSL for connections, automatic security patches and IP-based access restrictions are part of the service. Enterprise adds VPN access and encryption at rest. Those Enterprise lines are not included because you picked PostgreSQL. They are included because you picked Enterprise.
A self-managed Cisco appliance is yours to run. The managed cluster firewall is rules you add, on a firewall we run. No extra firewall means you are relying on the SSL and the IP restrictions without that extra tier. Choose the tier that matches who is allowed to open the port. A database that accepts the whole internet, with a password in an application config, is a weak arrangement on any engine. Restrict the IP to the application, the Kubernetes egress you actually use, and the people who administer it.
The Cisco hardware firewalls on the enterprise menu are a rack product of their own, with ASA and Firepower plans. They are related, and they are not automatically part of a Starter database. If you need a device in a rack, that is the firewall page. If you need the database's own firewall choice, that is the option at database checkout.
Where the application should live
A small site on Plesk shared hosting can keep a small application database in the hosting account. Move to this product when you want a chosen engine, a dedicated address, a stated backup retention, room to add a replica, and support that is about the database. The storage steps, 20 GB, 50 GB, 100 GB and 250 GB, are the plan sizes. They are a better fit than hoping a shared account has room.
Kubernetes applications should treat this database as the hosted MariaDB, or as the public address you were given, and should put the credentials in the namespace as a secret you manage. The database password does not belong in the image. The namespace login cannot see another customer's namespaces, and it should not be able to see this database except as a client. Scaling the application with KEDA does not scale the database plan. If the database needs more RAM, that is a plan change, and the FAQ says most of those changes can be done with little or no downtime.
MongoDB and SQL Server 2022 Standard are on the same FAQ list. This article does not pretend they are MariaDB or PostgreSQL. If the application is MongoDB, choose MongoDB. If it is SQL Server, choose SQL Server 2022 Standard. The backup, address and high-availability pattern is the plan, not the engine. The engine is still the one the application speaks.
A practical order
Name the engine first. Then name the environment: one instance for production is Starter or larger; production that must keep an address through a node failure needs the high-availability option or Enterprise. Then name the disk you have today and the disk you will have in a year, and pick 20, 50, 100 or 250 GB on that basis. Then name how far back a restore must reach, and add weeks at £5 per month or use Enterprise's 28 days. Then name who may connect, and pick the firewall tier.
Ask for migration help when the data already lives somewhere else. Plan a rehearsal. Cut over when the rehearsal restore matches what the application expects. Keep the old instance long enough to notice a missing table. The new address, dedicated IP or shared virtual IP, is the one in the application config after that.
The guide Choosing MariaDB or PostgreSQL is the decision version of this article. The topic Managed database hosting is the landing page. The order page is database hosting. Start there when you already know the engine and the size. Stay here when you needed the backup rules and the address written out in one place.
After the instance is up
Put the connection string in the application, restrict the IP, and run the application's own migration against a copy before you point production at the new address. Check that a backup from day one can be named, even if you do not restore it yet. Note whether you bought 7 days or longer. Note whether the address is a dedicated IP or a shared virtual IP, and write that into the runbook so a later failover does not trigger a search for a new hostname.
Watch disk on the plan you bought, not on the disk of a laptop that happens to hold a dump. 20 GB fills faster than a spreadsheet suggests once indexes and binary logs, or the PostgreSQL equivalents you actually use, are counted. Moving from Starter to Standard, or up the list, is the scaling path the FAQ describes. It is a better week than an emergency restore from a window that has already expired.