Remote MySQL: when not to

You should not use remote MySQL as the everyday database for a live site when PHP and MySQL sit in different cities. The extra network round trip shows up as slow wp-admin, hanging cart clicks, and TTFB you feel on every cache miss. Keep the app and the primary database on the same host unless you have a measured reason to split them.

What the round trip actually costs

A page that looks cached can still hit the database on admin paths, carts, and logged-in views. Each query pays for the ocean latency plus the query time itself. Twenty queries at roughly 80 ms each add well over a second before PHP even starts to render. LiteSpeed cache will not fix wp-admin when the database is far away. On shared hosting, remote MySQL is a cPanel checkbox plus a host you allow. That setup fits a reporting box or a one-off dump, not a shop with PHP in one region and MariaDB on another continent.

When remote MySQL is the right tool

Use remote access for a replica that analytics can query, a BI tool that should not run on the web node, or a short migration with a temporary dual-write. Those are deliberate splits you can measure. Prefer SSL when traffic leaves the server. Store the password in your tunnel or client config, not in chat history. An SSH tunnel from your laptop to port 3306 lets you use a desktop client without opening MySQL to the public internet.

Close the door if you opened it by mistake

Opening MySQL to % because a GUI asked for it creates a public database and a password that will eventually leak. Restrict the host list to real IPs, rotate the password, and turn the remote checkbox off if the app never needed it. Physics still collects TTFB on every distant query. Remote MySQL does not scale forever; it scales until the round trip becomes the page.

Engine differences are a separate issue. If the remote end is MySQL 8 and your app was written against MariaDB on shared hosting, read the error before you blame the network. See MariaDB vs MySQL, in practice.