How to Use Managed Cloud SQL with WordPress

Short answer: create a managed MySQL-compatible database and a least-privileged user, make the database reachable from your WordPress runtime, then set WordPress’s database name, username, password and host in wp-config.php. The host is provider-specific: it can be a Cloud SQL Auth Proxy localhost endpoint or Unix socket, or an Amazon RDS/Aurora endpoint and port. Verify the connection with WP-CLI before moving traffic.

Managed SQL separates the database from the WordPress application server. The provider operates database infrastructure, backups and maintenance, while your WordPress runtime still needs a network route, credentials and a compatible MySQL protocol. This guide covers the architecture, Google Cloud SQL with the Auth Proxy, AWS Lightsail with Aurora or RDS, configuration, verification, production checks and failure diagnosis.

1. Understand the architecture

A normal deployment has four pieces:

1. WordPress runtime: a VM, container, managed host or Lightsail instance running PHP and a web server.
2. Managed database: Cloud SQL, Amazon RDS MySQL, Aurora MySQL or another MySQL-compatible service.
3. Network path: a private network route, VPC peering connection, proxy socket or provider endpoint.
4. Database identity: a database name, application user and password, plus the permissions needed by WordPress.

WordPress’s installation guidance has historically listed MySQL 5.7 or MariaDB 10.3 and newer, but requirements can change. Check the current WordPress requirements and your provider’s supported engine versions before creating the instance.

2. Collect the connection values

Have these values ready before editing WordPress:

Value	What it means	Where it comes from
Database name	The schema WordPress will use	Created in the managed service
Username and password	Application credentials	A dedicated database user, not an administrator account
Host	Address or local listener WordPress connects to	Provider endpoint, proxy address or Unix socket
Port	MySQL listener port, normally 3306	Provider connection details
TLS or proxy settings	How the connection is encrypted and authorized	Cloud provider documentation and your runtime

Keep the password in your deployment secret store or environment configuration. Do not commit it to a public repository, paste it into a ticket or place it in client-side JavaScript.

3. Create the managed database and user

Choose a compatible engine and region

Select MySQL or MariaDB compatibility supported by the WordPress version you deploy. For AWS Lightsail-to-Aurora, AWS documents placing the Aurora database in the same AWS Region as the Lightsail instance. Region choice also affects latency and the network path available to the application.

Create a least-privileged application user

Create a database and user through the provider console or SQL client. The exact administrative command differs by engine and provider. A generic MySQL example is:

CREATE DATABASE wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wordpress_app'@'%' IDENTIFIED BY 'use-a-secret-from-your-secret-store';
GRANT ALL PRIVILEGES ON wordpress.* TO 'wordpress_app'@'%';
FLUSH PRIVILEGES;

Use the provider’s documented user-management workflow when it supplies one. Restrict the account’s source hosts or network access where the service supports it. WordPress needs to create and alter tables during installation and plugin updates, so an account with no write access will fail later even if a read-only connection test succeeds.

4. Make the database reachable

Google Cloud SQL with the Auth Proxy

Google’s Cloud SQL Auth Proxy authorizes and encrypts connections, avoiding authorized networks or manual SSL setup in supported configurations. Give the connecting identity the Cloud SQL Client role, which includes cloudsql.instances.connect, enable the Cloud SQL Admin API and run the proxy in the same application environment with appropriate credentials. See the Cloud SQL Auth Proxy documentation.

The proxy normally listens on 127.0.0.1 for TCP or exposes a Unix socket. WordPress then connects to that local listener; it does not use a public Cloud SQL address in the proxy pattern. If you intend to use a private IP, the proxy must run on a resource with VPC access and be instructed to use private IP.

# Example shape; use the current provider command and your instance connection name
cloud-sql-proxy INSTANCE_CONNECTION_NAME --address 127.0.0.1 --port 3306

A local quickstart is suitable for development or a connection check, not a complete production deployment. In production, supervise the proxy process, grant only the required identity permissions and prevent its listening port from being exposed externally. Run it under your service manager or container orchestration system and make its health part of deployment monitoring.

AWS Lightsail WordPress with RDS or Aurora

AWS’s Lightsail-to-Aurora example requires VPC peering, an Aurora database in the same AWS Region and a running database. Add a security-group rule allowing the expected source and MySQL port from the WordPress-to-database path. Do not treat this as universal AWS networking guidance: the exact route depends on your account, VPCs and hosting topology.

For a direct RDS connection, AWS instructs you to use the instance’s endpoint DNS name as the host and its configured port. Restrict inbound access to the WordPress runtime and use TLS where applicable. The RDS connection documentation covers endpoint, port and encrypted connection considerations.

5. Configure WordPress

WordPress reads its database settings from wp-config.php. Back up the file, edit the values and keep the file readable only by the account that needs it.

define( 'DB_NAME', 'wordpress' );
define( 'DB_USER', 'wordpress_app' );
define( 'DB_PASSWORD', getenv( 'WORDPRESS_DB_PASSWORD' ) );
define( 'DB_HOST', '127.0.0.1:3306' );
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );

For Cloud SQL Auth Proxy TCP mode, DB_HOST can be 127.0.0.1:3306. For Unix-socket mode, use the socket path required by the proxy and PHP MySQL driver. For RDS or Aurora, use the provider endpoint and port, for example:

define( 'DB_HOST', 'my-database.cluster-abc123.us-east-1.rds.amazonaws.com:3306' );

Never copy a host value between providers without checking the actual runtime topology. A proxy host is local; an RDS host is a remote endpoint. If your platform injects secrets as environment variables, adapt the password-loading line to that platform rather than hard-coding a credential.

6. Verify before relying on the site

First test with the same network identity and credentials WordPress uses. WP-CLI’s wp db connect reads the database credentials from wp-config.php; see the WP-CLI command reference.

cd /var/www/html
wp db connect
wp db query "SELECT VERSION(), DATABASE();"
wp core is-installed

If the command opens a MySQL prompt and the query returns the expected database, the basic path works. Then load the site, sign in to /wp-admin/, open a page that reads posts and perform a controlled write such as updating a draft. Review PHP, web-server, proxy and managed-database logs while doing so.

7. Troubleshoot in a fixed order

Symptom	Likely cause	Fix
Error establishing a database connection	Wrong name, user, password or host	Compare every wp-config.php value with the provider connection details; test with wp db connect.
Connection refused to 127.0.0.1	Proxy is stopped, listening on another port or bound to another address	Check the supervised proxy process and listener, then use the exact local port or socket in DB_HOST.
Connection times out to an RDS endpoint	Missing VPC route, peering or security-group ingress	Confirm the documented Lightsail peering path, same-region placement and inbound rule for the database port.
Cloud SQL permission denied	Identity lacks Cloud SQL Client permission or the API is disabled	Grant the required role, enable the Cloud SQL Admin API and restart the proxy with valid credentials.
Access denied for user	Password mismatch, wrong user host restriction or wrong database	Reset the secret through the provider, verify the username and grant the required permissions on the intended schema.
SSL or certificate error	Client and provider TLS settings do not agree	Follow the provider’s current TLS instructions; with Cloud SQL, prefer the supported Auth Proxy path.
Site connects but updates fail	User can read but cannot create or alter tables	Review grants and confirm the application account can perform the operations required by WordPress and its update process.
Intermittent failures	Proxy restarts, maintenance, exhausted connections or overloaded database	Inspect proxy and database metrics, set connection limits appropriate to PHP workers and check maintenance events.

Diagnose in this order: credentials and database name; endpoint, socket and port; database availability; firewall, security group and VPC path; proxy identity and API permissions; TLS configuration; then client and engine compatibility. This isolates application configuration from network and provider control-plane problems.

8. Production checklist

• Keep the database private when your network design permits it.
• Allow inbound traffic only from the WordPress runtime or proxy path.
• Use encrypted connections and rotate application credentials.
• Run the Cloud SQL Auth Proxy as a supervised production process, not an unattended shell command.
• Configure backups, maintenance windows and recovery procedures in the managed service. RDS exposes security, availability, backup and maintenance settings in its creation workflow; choose them for your recovery requirements.
• Monitor connection count, query latency, storage, CPU, memory and failed connections.
• Size PHP workers and database connections together. More web workers can exhaust the database connection limit.
• Test restore and failover procedures in an environment that resembles production.

Do not promise a fixed response time or uptime from a database plan without workload-specific measurements. Performance depends on query patterns, indexes, PHP concurrency, region distance, cache configuration and the selected database size.

9. Cost and reliability considerations

Managed SQL pricing usually combines instance capacity, storage, backups, network transfer and optional high-availability features. Compare the provider’s current calculator and plan details before budgeting. A smaller database can reduce cost but may increase contention; a larger or highly available configuration can improve operational resilience while increasing spend. Keep WordPress and its database close enough to limit network latency, and use application or page caching for read-heavy traffic.

Reliability comes from the complete path, not only the database service. A healthy database cannot compensate for an expired proxy credential, a missing route, a closed security-group port or an application server that cannot resolve the endpoint. Alert on each layer separately.

10. Or skip the browser setup

If your WordPress work also needs repeatable page captures for release notes, visual checks or documentation, ScreenshotNeo provides a single screenshot request without maintaining a browser. Before capture it accepts cookie or consent banners and removes more than 60 known consent platforms, newsletter popups and chat widgets; each step can be disabled. Bot checks, blank pages, timeouts, failed loads and cache hits are not billed, and response headers identify the page verdict and whether the request was billed.

See the ScreenshotNeo API documentation for all options. This is the smallest call:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

You can request full-page captures with lazy images loaded, a CSS-selected element, dark mode, device presets or any viewport, retina scale, PDF output, custom CSS and JavaScript, clicks, waits, hidden selectors, blocked ads or resources, custom headers and cookies, timezone and geolocation, transparent backgrounds, resizing, caching with a chosen TTL, signed image links, asynchronous jobs with signed webhooks, bulk capture for up to 100 URLs and usage data. An MCP server exposes take_screenshot, get_page_info and capture_pdf to Claude, Cursor and other MCP clients.

There are 1,000 free screenshots each month with no card. Paid plans start at $5 for 3,000 shots; every feature is available on every plan. Create a free ScreenshotNeo account.

11. FAQ

Can WordPress and Cloud SQL be in different regions?

They can be, but the network path and latency must be acceptable. The AWS Lightsail-to-Aurora example specifically documents same-region placement, so follow the provider topology for your deployment.

Should I expose MySQL to the public internet?

Prefer a private route, proxy or restricted security-group path. If a public endpoint is unavoidable, limit source ranges and require encryption according to the provider’s current guidance.

Is the Cloud SQL Auth Proxy a database?

No. It is a client-side connection component that authorizes and encrypts traffic between the application and Cloud SQL. WordPress still connects to the managed database through the proxy’s local listener.

Why does a command-line test work while the site fails?

The web process may use a different PHP configuration, environment, Unix user, secret, socket path or network namespace. Run the test from the same runtime and inspect the web application’s logs.

What should I change first when migrating from local MySQL?

Export and import the database, create the managed user, establish the network path, update DB_HOST and credentials, then verify with WP-CLI before changing DNS or sending production traffic.