Before creating a database
Confirm that the plan still has an included database slot and choose a MySQL version supported by the application. Decide the name before creation: the generated database name and username cannot normally be renamed later. Use a unique strong password and store it in a password manager because it will not be shown again.
Create and record the connection values
Create a database with an available capacity, compatible engine and supported version, then provide the requested name suffix and password. Creation can take several minutes. When it finishes, record four distinct values: database hostname, database name, username and port. The hostname is not the database name, the hosting IP or localhost.
Connect the application
Enter the exact connection values in the application's configuration file or installer. Included databases are intended for applications running on the hosting service and may not accept direct public connections from a desktop client. Test a read and a harmless write. If the application reports an unknown host, verify the hostname character for character; if it reports access denied, verify database name, username and password together.
Connection and capacity limits
Included MySQL databases accept up to 30 simultaneous connections. Avoid oversized pools and persistent connections that are never released. When storage is exceeded, the service can place the database in read-only mode: remove unnecessary data or increase capacity, then recalculate usage before expecting writes to resume.
Import an SQL backup
Imports accept .sql, .txt or .gz exports up to 2 MB. Preserve existing tables for an incremental script; empty the database first only when the export is a complete replacement and a current recovery copy already exists. Large exports should be split safely or imported through an application-side tool designed for resumable imports.
Create backups before a change
Create a dump before application upgrades, schema changes or a destructive import. A downloadable SQL export is portable; a retained platform copy is convenient for an in-place restore but should not be the only copy of business-critical data. Verify that an export contains both schema definitions and the expected tables before relying on it.
Restore a consistent application
Select the correct database and restore point, then wait until the database accepts both reads and writes. If the incident also changed application files, restore a matching file snapshot. Clear the application's cache and test login, content retrieval and one reversible write. Mismatched file and database versions can leave an application unusable even when both restores succeeded individually.
Remove a database safely
Identify every application using the database and retain a verified export before deletion. Uninstalling WordPress, Joomla or PrestaShop can leave the database resource behind, while deleting the database first makes the remaining application fail immediately. Treat application removal, file removal and database deletion as three separate decisions.
