This is part of a series on the modern web stack, written from a WordPress developer’s seat for people who’ve built on the web for years and still hit stack terms they can’t define. The goal is literacy, enough that you can read any stack list and know what each piece does.
Each post has a 10-15 minute audio companion, generated with NotebookLM, for the gym or the commute.
For about fifteen years my mental model of “the database” was the same as my mental model of “WordPress hosting.” You bought a hosting plan, the plan included MySQL, you ran queries through WPDB or phpMyAdmin, and the database lived in a server room owned by the company that hosted your PHP files. You didn’t pick a database. You picked a host and got whatever MySQL came with it.
Then I started reading about Supabase, Neon, PlanetScale, Turso and Cloudflare D1, and assumed the modern crowd had rebranded shared MySQL with prettier marketing pages. They hadn’t. Where data lives and how application code talks to it has changed, and that matters even if you never leave WordPress.
This post covers what changed, what each of these services is, and what a WordPress veteran needs to know when “Supabase” comes up in a planning meeting.
The Database Became a Service
The database stopped being part of the host and became a product in its own right.
In a traditional WordPress setup, MySQL runs on the same machine as your PHP code and the application connects through a local socket. Performance is excellent, since you can’t beat localhost, but you get whatever the host gives you. Scaling the database means scaling the whole host. A read replica in another region only exists if your host offers one. The database is welded to the application server.
In the modern stack, the database runs on someone else’s infrastructure and your code reaches it over the network. The database company specializes in running databases well, and you specialize in everything else.
Pick the right database for the job
Postgres for relational data with complex joins, a Redis-style store for caching and queues, a search index for search, a serverless edge database for tiny low-latency lookups. You combine them in application code instead of running them all on one box.
Scale the database on its own
For a Black Friday spike you bump the database tier without touching the app. A read replica in Singapore is a button click. Most managed databases now auto-scale without you watching.
Deploy the app anywhere
The database is a URL with credentials, so your app can run on Vercel, Cloudflare, Fly.io or your laptop and talk to the same data. That’s impossible in the WP-on-cPanel model, where moving the app means moving the database.
Stop running your own MySQL
Patching, backups, replication and failover are the service’s job. You pay for it, and for a solo developer the time saved is worth it.
The cost is that every query is a network call. A query that took 0.5ms on localhost takes 5-50ms over the network. Modern apps issue fewer queries per request, so it hurts less in practice, but the constraint shapes the rest of the stack: connection pooling, edge caching and query batching all exist because of it. For where the app code runs relative to the database, see serverless and edge explained.
The WordPress Analogue
Modern cloud databases are to MySQL what Kinsta is to bargain shared hosting.
The engine is usually still Postgres or MySQL underneath. Supabase is Postgres and PlanetScale is MySQL. The difference is operational. 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 (the next post covers those), and you still have tables, rows and indexes. The plumbing changed and the language stayed.
The closest WordPress parallel is a WordPress that required you to bring your own MySQL connection string. It would still be WordPress, with its data living anywhere. Modern frameworks like Next.js assume exactly that from day one.
The Database Services You’ll Meet
These are the main databases-as-a-service in the modern stack:
| Service | Engine | Best for | Strengths | Watch out for |
|---|---|---|---|---|
| Supabase | Postgres | Full-stack apps, auth, storage, realtime | Bundles DB, auth, storage, realtime and edge functions. Generous free tier. | Easy to over-rely on the bundled features; vendor coupling. |
| Neon | Postgres | Pure database service, branching workflows | Branchable Postgres (git-style DB branches per PR). Strong serverless model. | Smaller ecosystem, no bundled auth. |
| PlanetScale | MySQL | Teams coming from MySQL, schema migrations | Schema branching, a strong migration story, no-downtime alters. | Pulled the free tier in 2024; pricing is steeper. |
| Turso | SQLite (libSQL) | Edge-replicated, embedded scale | SQLite at the edge, replicated globally. Cheap, fast for read-heavy loads. | Limited write throughput, smaller community. |
| Cloudflare D1 | SQLite | Cloudflare Workers projects | Tightly integrated with the Cloudflare runtime. Fits the edge model. | Tied to Cloudflare; not portable. |
| AWS RDS / Aurora | Postgres, MySQL | Enterprise teams, AWS-centric stacks | Mature, predictable, integrates with everything in AWS. | Operational overhead, pricing complexity, not serverless-friendly. |
| MongoDB Atlas | MongoDB (document) | Document-shaped data, flexible schemas | Mature managed Mongo, generous free tier, decent edge story. | Non-relational, so most of the SQL ecosystem doesn’t apply. |
For a default-stack 2026 project, Supabase or Neon are the typical choices. Pick Supabase if you want auth, storage and realtime bundled with the database. Pick Neon if you want pure Postgres with branching and prefer to bring your own auth (auth in 2026 covers those options).
A separate decision is whether you need a database at the edge, with low-latency reads from anywhere in the world. Most apps don’t. The latency gain matters at scale, and for the first ten thousand users it rarely justifies the added architecture.
What This Changes for WordPress People
The database constraint loosens
You can point WordPress at any MySQL-compatible database. With PlanetScale or another Vitess-based service, a WordPress site can run against a database that scales separately from the application. For high-traffic content sites that’s useful: WP application servers behind a CDN, with the database on a managed service that absorbs the spikes.
Hybrid stacks become viable
WordPress as the CMS, a modern frontend as the rendering layer, and a cloud database that both sides use for non-content data such as user accounts, transactions and telemetry. The data lives in one place and the rendering happens where it makes sense. The headless WordPress post picks this up.
AI dev tools work better
An AI agent that generates code can connect to a Supabase or Neon database directly through the connection string and the REST API. It can’t easily reach shared MySQL on Kinsta unless you expose it, which you shouldn’t. Knowing this layer makes AI-paired development more productive.
What Slows Cloud Databases Down
Latency adds up
A WordPress page that runs ten queries on localhost spends about 5ms in the database. The same page over a network adds 50-500ms depending on geography. The fixes are to host the app close to the database, batch queries, or cache results. Most cloud database providers offer connection pooling and edge caching for this reason.
Connection pooling is mandatory
Serverless functions spin up and tear down constantly, and 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 and others). Configure them or the app will fail at random under load.
Free tiers have limits
Supabase’s free tier pauses your database after a week of inactivity, and Neon’s free tier caps compute hours. Both are fine for a side project. For client work, budget the paid tier from day one.
Vendor coupling is sneaky
Supabase’s auth, storage and realtime are good, and they tie you to Supabase. The data stays portable because it’s Postgres, but the auth flows, RLS policies and storage links all need rewriting if you migrate. Use the bundled features on purpose.
Backups are still your problem
Every managed database advertises backups, and most do them well. The operational test is whether you can restore to a specific point in time, in production, in under thirty minutes. Run that test once on day one of any project. Plenty of teams have learned the answer during a disaster.
Get a Feel for the Trade-offs
YouTube
- “Postgres in 100 Seconds” by Fireship, then “Choosing a Database in 2024” by Theo (t3.gg). Orientation first, opinion second.
- “Database Branching with Neon” on the Neon channel (about 15 minutes). The branching workflow changes how you think about schema changes.
Official docs
- Supabase docs. The Getting Started walkthrough is among the better onboarding experiences in modern dev tooling.
- Neon docs. Start with the branching pages, since the workflow is unfamiliar even to experienced Postgres users.
- PlanetScale docs. The deployment pages are worth reading even if you never use PlanetScale, because the no-downtime migration story is educational on its own.
The next post covers the layer between application code and the database: the ORM. If WPDB is as far as you’ve gone, Drizzle, Prisma and Kysely will look both familiar and alien.
Related
Leave a Reply