MySQL vs PostgreSQL for a Web Application: Which to Choose

For a new custom web application such as a CRM, client portal or SaaS product, PostgreSQL is usually the better default: it enforces data rules strictly, handles JSON data well and has a large range of extensions. MySQL (or its close relative MariaDB) is the right choice when the software already expects it, which includes WordPress and WooCommerce, or when your team and hosting are built around it. Both are free, mature and fast enough for almost any small or mid-sized business.

This guide is for founders and business owners who are commissioning an app and want to understand the database decision without reading a manual. It explains where the two really differ, where they do not, and what it costs to change your mind later.

#Where the two databases actually differ

For most business apps, the differences that matter are data integrity, JSON handling, extensions and the ecosystem around each database. Raw speed is rarely the deciding factor at small and medium scale, because both are well proven under heavy load.

The table compresses a lot. The sections below explain the rows that most often change a decision.

#Data integrity: what stops bad data getting in

Data integrity means the database itself refuses data that breaks your business rules, such as an invoice with a negative total or an order linked to a customer who does not exist. When the database enforces these rules, a bug in the app cannot quietly fill your tables with nonsense.

PostgreSQL has long been known for being strict here, with foreign keys, CHECK constraints and a wide choice of data types that reject values which do not fit.

MySQL has closed much of the gap. Its own manual notes that before MySQL 8.0.16, a basic CHECK (expr) constraint was "parsed and ignored". Current versions create and enforce CHECK constraints by default. The practical lesson for a business owner is simple: if you are running an older MySQL server, or an app built on habits from that era, do not assume the database is guarding your rules.

#JSON data: flexible fields without losing search

Many modern apps store some data as JSON, a flexible format for things like custom form answers, product options or settings that vary per client. Both databases store JSON, but they differ in how well you can search it.

PostgreSQL offers two types. The PostgreSQL documentation describes jsonb as stored in a binary format that is "significantly faster to process", and recommends that most applications use jsonb. It can be indexed with a GIN index, so a query such as "find every lead whose answers include this value" can stay fast as the table grows.

MySQL's native JSON type validates documents on the way in and stores them in a binary format. According to the MySQL 8.4 manual, a JSON column cannot be indexed directly; instead you index a generated column that pulls out one value, or use a multi-valued index for arrays. That works well when you know in advance which fields you will filter on, and is less flexible when you do not.

If your app will lean on flexible, client-defined fields, which is common in CRMs, form builders and multi-tenant SaaS, PostgreSQL's JSON support is a real advantage.

#Extensions: features you would otherwise build

PostgreSQL is designed to be extended. Its documentation says extensions "can function just like features that are built in". In business terms, this means some features are an installation rather than a project:

• PostGIS for maps, delivery zones, "nearest branch" searches and other location features.
• pgvector for storing AI embeddings, which power semantic search and AI assistants that answer from your own documents.
• pg_cron for scheduled jobs such as nightly clean-ups or reminder emails, run inside the database.

Supabase's documentation lists all three as extensions you can switch on from its dashboard. MySQL has its own strengths, including spatial data types, but it does not have an extension ecosystem of the same breadth. If your roadmap includes location search or AI features, that tips the balance towards PostgreSQL.

#Hosting options: managed services, Supabase and shared hosting

Both databases are easy to host, but where you can host them is different, and that affects monthly cost and who looks after backups.

Managed cloud databases. Amazon RDS lists both PostgreSQL and MySQL among its supported engines, alongside MariaDB and Aurora editions compatible with each, and the other large clouds have their own managed versions too. A managed service handles patching, backups and failover, which is usually worth the cost for a business app holding customer data.

Supabase. Supabase's documentation states that every project gets "a full Postgres database, not a Postgres abstraction", with authentication, file storage and realtime features built around it. At the time of writing (November 2026), its pricing page (opens in a new tab) lists a Free plan with a 500 MB database per project that pauses after a week of inactivity, and a Pro plan from USD 25 a month. Prices change, so check the page before budgeting. My article on Supabase for business apps covers when it fits and where lock-in starts.

Shared and cPanel hosting. Almost every shared hosting plan includes MySQL or MariaDB, because that is what WordPress needs. PostgreSQL on shared hosting is less common. If you are set on a low-cost shared host for a small PHP app, check what it supports before you decide.

#WordPress and WooCommerce: the decision is already made

If your project is a WordPress website or a WooCommerce store, you do not choose between these two. WordPress's requirements page (opens in a new tab) recommends MySQL 8.0 or greater, or MariaDB 10.11 or greater, and WordPress core does not support PostgreSQL.

MariaDB is a close relative of MySQL, and WordPress lists the two as alternatives. For a WordPress owner, the useful questions are about version and care, not brand:

• Is the database version one that still receives security fixes?
• Are there daily backups stored away from the server?
• Are large tables, such as old WooCommerce orders or plugin logs, slowing the site?

That last point is where database work pays off on WordPress sites, and it is part of what database optimisation and migration covers.

A common and sensible setup is to keep the marketing site and shop on WordPress with MySQL, and build a separate custom app, such as a portal or internal tool, on PostgreSQL. The two talk through an API. My comparison of Next.js and WordPress explains when that split makes sense.

#What a later migration really involves

Switching an existing app from MySQL to PostgreSQL, or the other way, is a project, not a button. The data itself can be moved with tools, but the work is in everything around it.

The parts that take time are usually:

1. Data types that do not match exactly. Dates, booleans, auto-incrementing IDs and text collation behave differently and need checking table by table.
2. SQL written for one database. Queries using database-specific functions must be rewritten and tested.
3. Stored procedures and triggers. Any logic living inside the database has to be rewritten in the other dialect.
4. The cut-over itself. New data keeps arriving while you migrate, so you need a short freeze or a sync plan, plus a way back if something fails.

For a small app with clean code, this can be a modest job. For a large app with years of hand-written SQL, it can take weeks of careful testing. The cheapest migration is the one you avoid by choosing well at the start, which is why this decision belongs in the planning stage of any custom web application.

#How to choose: a short decision guide

Choose based on what the software needs and who will look after it, not on which name is more fashionable.

Choose PostgreSQL when:

• You are building a new custom app, SaaS product, CRM or portal from scratch.
• You want Supabase, or a stack that already assumes PostgreSQL.
• You expect flexible per-client fields, reporting, location features or AI search.

Choose MySQL or MariaDB when:

• The project is WordPress, WooCommerce or another platform that requires it.
• You are extending an existing MySQL app and a migration is not justified.
• Your hosting or in-house team is set up around MySQL and the app is simple.

If you are planning a new build and want a second opinion on the stack, my guide to planning a web app MVP shows where this decision fits. If you have an existing database that is slow or needs moving, the database optimisation and migration service starts with an audit and a written quote.