Beyond Shared MySQL: Cloud Databases for WordPress Developers

This is part of an ongoing series I am writing as I work my way through the modern web stack from a WordPress developer’s perspective. The series is aimed at WordPress veterans who, like me, have built things on the web for years and feel quietly behind the curve. The goal is broad literacy, not deep mastery. By the end you should be able to read any modern stack list and know what each piece is doing.

Each post comes with an audio companion (10-15 minutes, generated via NotebookLM) for gym or commute listening. Press play below if that suits you better than reading.

Hook

For about fifteen years my mental model of “the database” was identical to my mental model of “WordPress hosting.” You bought a hosting plan, the hosting plan included MySQL, you ran some queries through WPDB or phpMyAdmin, and the database lived in a server room owned by the same company that hosted your PHP files. The two were married. You did not really pick a database; you picked a host, and you got whatever MySQL came with.

Then I started reading about Supabase, Neon, PlanetScale, Turso, and Cloudflare D1, and I assumed the modern crowd had simply rebranded shared MySQL with prettier marketing pages. They had not. Something has genuinely changed about where data lives and how application code talks to it, and the change matters even if you never leave WordPress.

This module is the database section of the modern stack tour. What changed, what each of these services actually is, and what a WordPress veteran needs to know to avoid getting lost when “Supabase” comes up in a planning meeting.

Core Concept

The big shift is that the database stopped being part of the host and started being a service in its own right.

In a traditional WordPress setup, MySQL runs on the same physical machine as your PHP code. The application connects through a local socket. Performance is excellent (you cannot beat localhost), but you are stuck with whatever the host gives you. If you want to scale the database, you have to scale the whole host. If you want a read replica in another region, you cannot have it unless your host offers it. The database is welded to the application server.

In the modern stack, the database is a separate service running on someone else’s infrastructure. Your application code connects to it over the network. The database company specialises in one thing: running databases well. Your application company (or you) specialises in everything else.

This decoupling unlocks a few things at once.

You can pick the right database for the job without changing host. Postgres for relational data with complex joins. A separate Redis-style key-value store for caching and queues. A specialised search index. A serverless edge database for tiny low-latency lookups. You combine them in your application code rather than running them all on one box.

You can scale the database independently. Need to handle a Black Friday spike? Bump the database tier without touching the app. Need a read replica in Singapore? Click a button. Most managed databases now offer auto-scaling that handles this without you watching it.

You can deploy your application anywhere. Because the database is just a URL with credentials, your app can run on Vercel, Cloudflare, Fly.io, or your laptop and talk to the same database. This is impossible in the WP-on-cPanel model, where moving the app means moving the database.

You stop running your own MySQL. Patching, backups, replication, failover: all handled by the service. You pay for this, but the time saving is real, especially as a solo developer.

The cost is that everything is a network call. A query that used to take 0.5ms on localhost now takes 5-50ms over the network. This matters less than you would think (modern apps issue fewer queries per request) but it shapes how the rest of the stack is built. Connection pooling, edge caching, query batching — all the modern data patterns come from this constraint.

The WordPress Analogue

Mental model: Modern cloud databases are to MySQL what Kinsta is to bargain shared hosting.

The actual database engine in most cases is still Postgres or MySQL under the hood. Supabase is Postgres. PlanetScale is MySQL. The difference is operational, not technical. Someone else runs the database expertly, exposes it via a URL, and gives you a dashboard and an API. You still write SQL (or queries through an ORM, covered in the next module), you still have tables and rows, you still index things. The plumbing changed, not the language.

The closest WordPress parallel: imagine if WordPress required you to bring your own MySQL connection string. The app would still be WordPress. The data would just live anywhere. That is what modern frameworks like Next.js assume from day one.

The Landscape

The main databases-as-a-service you will meet in the modern stack:

For a default-stack 2026 project, Supabase or Neon are the typical choices. Supabase if you want the bundled auth/storage/realtime alongside the database. Neon if you want pure Postgres with branching and prefer to bring your own auth.

A separate decision is whether you need a database at the edge (low-latency read access from anywhere in the world). Most apps do not. The latency gain matters at scale; for the first ten thousand users it rarely justifies the architectural complexity.

What This Changes for WordPress People

Three practical implications.

The first is that WordPress’s database constraint matters less. WP-CLI lets you point WordPress at any MySQL-compatible database. With PlanetScale (or Vitess-based services), you can run a WordPress site against a database that scales differently from the application. For high-traffic content sites this is genuinely useful: WP application servers behind a CDN, database on a managed service that handles the spikes.

The second is that hybrid stacks become viable. WordPress as the CMS, a modern frontend as the rendering layer, and a cloud database that both sides talk to for non-content data (user accounts, transactions, telemetry). The data lives in one place, the rendering happens where it makes sense. We will revisit this in the headless WordPress module.

The third is that AI dev tools work better with cloud databases. AI agents that generate code can connect to a Supabase or Neon database directly using the connection string and the database’s REST API. They cannot easily connect to shared MySQL on Kinsta unless you expose it, which you should not. Modern stack literacy here unlocks productive AI-paired development.

Watch Out

A handful of traps.

Latency adds up. A WordPress page that runs ten queries on localhost takes ~5ms in database time. The same page over a network adds 50-500ms depending on geography. The fix is either to host the app close to the database, batch queries aggressively, or cache results. Most cloud database providers offer connection pooling and edge caching for this reason.

Connection pooling is non-optional. Serverless functions spin up and tear down frequently. Each one wants its own database connection. Without a pooler, you exhaust Postgres connection limits fast. Supabase, Neon, and PlanetScale all ship poolers (PgBouncer, Hyperdrive, etc.). Configure them or your app will randomly fail at scale.

Free tiers are real but limited. Supabase free tier pauses your database after one week of inactivity. Neon free tier has compute hour limits. For a side project these are fine; for client work, budget the paid tier from day one.

Vendor coupling is sneakier than it looks. Supabase’s auth, storage, and realtime are great, but they tie you to Supabase. If you ever want to migrate, the data is portable (it is Postgres), but the auth flows, RLS policies, and storage links all need rewriting. Use the bundled features deliberately, not by accident.

Backups are your problem, even if the service handles them. Every managed database advertises backups. Most do them well. But the operational test is: can you restore to a specific point in time, in production, in under thirty minutes? Test this once on day one of any project. The number of stories about teams who never tested restores until disaster is depressingly large.

Going Deeper

If you want to develop a real sense of when to reach for which service, a few resources worth your time.

YouTube, gym or commute friendly:

• “Postgres in 100 Seconds” by Fireship, then “Choosing a Database in 2024” by Theo (t3.gg). Orientation and opinion in that order.
• “Database Branching with Neon” (Neon channel, ~15 min). Worth watching because the branching workflow genuinely changes how you think about schema changes.

Official docs worth bookmarking:

• Supabase docs. The “Getting Started” walkthrough is one of the better onboarding experiences in modern dev tooling.
• Neon docs. Especially the branching pages; the workflow is unfamiliar even to experienced Postgres users.
• PlanetScale docs. Read the deployment pages even if you do not use PlanetScale; the no-downtime migration story is educational on its own.

Next post in the series tackles the layer between your application code and the database: the ORM. If WPDB was as far as you have gone, Drizzle, Prisma, and Kysely will look both familiar and alien.

Related

What’s Beyond WordPress?

The Complete Guide to Local WordPress Development and Testing

Is There a WordPress Replacement in 2026? I Went Looking

My Thoughts on WordPress in 2020

Best WordPress Alternatives in 2026

Local WP vs Docker: When to Use Each for WordPress Development