Every plan includes MySQL databases, a click-through to phpMyAdmin, and per-database users. Here is the whole lifecycle: create, connect, inspect, import, export.
Create the database and its user
In the panel, open your site and go to Databases. Add database creates the database; names get your account’s prefix automatically, so shop becomes something like yoursite1_shop. Use the full prefixed name everywhere.
Add user creates a database user with its own password. A user is granted access per database, so one site can have a user that reaches everything and another that reaches only one database. For a typical app, one database plus one user is the whole setup.
phpMyAdmin is one click, not a login
Your site’s overview page has a phpMyAdmin quick link that signs you straight in. No separate username and password to store, no URL to remember. Everything a database admin screen is for lives there: browsing tables, running a query, fixing a value you should probably not be fixing in production.
Connect your application
Your app’s config wants four values: the prefixed database name, the username, the password, and the host. The first three come from the Databases page. The host is where people go wrong:
DB_HOST=localhost
Use localhost, written exactly like that. Not 127.0.0.1. Sites here run in their own containers, and inside a container 127.0.0.1 is the container’s own empty loopback. localhost routes through the socket your site is permitted to use. An app that connects fine elsewhere and refuses here with correct credentials is hitting this, and it costs people an afternoon every time.
Import and export
phpMyAdmin handles both. Export produces a .sql file of your database, which is also the sensible thing to do before any risky change: big plugin update, framework migration, manual query surgery. Import accepts the same format when you are bringing a site in from elsewhere.
For databases too large for a browser upload, run the import over SSH instead, or attach the file to a support ticket and we will load it for you.
Remote desktop clients
Database access is scoped per user, and by default a user’s access is local to the server, which is the right default: a database that accepts connections from the whole internet is a database being brute-forced from the whole internet. phpMyAdmin covers the browsing and querying that a desktop client is usually wanted for. If your workflow genuinely needs a direct remote connection, open a ticket and we will set it up for the specific user and source address rather than the world.