MySQL vs PostgreSQL in 2026: The PHP Developer’s Verdict

MySQL vs PostgreSQL is the database decision every PHP developer eventually has to defend to a client or tech lead, and in 2026 the honest answer is more nuanced than most surveys suggest. I’ve shipped both — MySQL under Drupal sites for a decade, PostgreSQL under newer Laravel APIs for the last two years — and the gap isn’t marketing fluff anymore. It shows up in production, at 2 a.m., when a write-heavy import job chokes on one engine and sails through on the other. Most comparison posts cherry-pick one benchmark suite and call it a day. This one uses 2026 sysbench numbers, real Drupal and Laravel compatibility data, and actual AWS RDS pricing to give you a verdict you can act on.

Is PostgreSQL Faster Than MySQL in 2026?

Yes, for writes and mixed workloads — but MySQL is still faster for simple reads. In 2026 sysbench OLTP testing on Ubuntu 24.04, PostgreSQL 17 sustained 21,338 single-row INSERT operations per second compared to MySQL 8.4’s 4,383 — a 4.9x write advantage for PostgreSQL.

Across 17 sysbench test scenarios, PostgreSQL posted 2.3x lower median latency overall and 3.5x lower latency specifically on write operations. For mixed read-write OLTP workloads — the kind most real applications actually run — PostgreSQL handled 6.6x more transactions per second than MySQL, hitting 2,886 TPS at 5.54ms average latency. MySQL claws back ground only on simple, read-only SELECT queries, where it outperforms PostgreSQL by 20-30%.

I’ve seen this exact pattern on a client’s order-processing system: MySQL handled the read-heavy product catalog fine, but the same schema on PostgreSQL processed nightly batch imports in roughly a third of the time once we moved the write-heavy inventory tables over. If your workload is read-dominated and simple, MySQL still has an edge. If it’s write-heavy, mixed, or involves complex joins, PostgreSQL wins by a wide margin.

Should You Choose PostgreSQL or MySQL for Laravel?

Choose PostgreSQL for new Laravel projects unless you have a specific reason not to. Eloquent doesn’t care which engine you use — migrations, relationships, and query builder syntax work identically on both. The difference only shows up at the database layer, and PostgreSQL wins there for most non-trivial apps.

// config/database.php - switching engines only changes this block
'pgsql' => [
    'driver' => 'pgsql',
    'host' => env('DB_HOST', '127.0.0.1'),
    'port' => env('DB_PORT', '5432'),
    'database' => env('DB_DATABASE', 'forge'),
    'username' => env('DB_USERNAME', 'forge'),
    'password' => env('DB_PASSWORD', ''),
    'charset' => 'utf8',
    'search_path' => 'public',
],

Where PostgreSQL actually pays off in Laravel apps: full-text search without a separate Elasticsearch cluster, native array and JSONB columns for flexible schemas, and row-level locking that holds up better under concurrent writes. I moved a Laravel-based reporting API from MySQL to PostgreSQL specifically to use JSONB columns for user-defined report filters — Eloquent’s whereJsonContains() worked without a single query change, and filter queries that took 400ms on MySQL’s JSON type dropped to under 100ms. Stick with MySQL only if your team has zero PostgreSQL operational experience and you’re on a tight deadline — that’s a real cost, not an excuse.

Does Drupal Support PostgreSQL in 2026?

Yes, Drupal core is fully compatible with PostgreSQL, but MariaDB (a MySQL fork) remains the officially recommended database across Drupal 10, 11, and 12. Drupal 12 will require PostgreSQL 18+ if you choose that engine, up from PostgreSQL 16+ on Drupal 11 and 12+ on Drupal 10.

Drupal’s database abstraction layer (DBAL) makes core queries portable across engines, but the practical risk lives in contributed modules. Plenty of contrib modules ship raw SQL or assumptions baked in during MySQL-only testing years ago. I ran a mid-size Drupal 10 site on PostgreSQL for a client who wanted JSONB for a custom entity field, and it worked cleanly for eleven months until a commerce module update shipped a MySQL-specific `ON DUPLICATE KEY UPDATE` query that silently failed on PostgreSQL — Drupal’s error handling swallowed it instead of throwing a visible exception, and stock counts drifted for three days before anyone caught it.

For a standard brochure or content site, stay on MariaDB/MySQL — the module ecosystem was built and tested against it. For a heavily custom Drupal build where you’re already writing most of your own modules and want PostgreSQL’s JSONB or full-text features, it’s viable, but budget extra QA time on every contrib module update.

How Do MySQL JSON and PostgreSQL JSONB Compare?

PostgreSQL’s JSONB is significantly faster for nested queries because it stores JSON in a parsed binary format with GIN indexing, while MySQL’s JSON type stores data as text and re-parses it on every access. In a benchmark against 1 million JSON documents, a nested query ran at 12,600 queries per second on PostgreSQL versus 3,400 QPS on MySQL — a 3.7x gap that widens as document complexity increases.

-- PostgreSQL: GIN index makes containment queries fast
CREATE INDEX idx_metadata ON products USING GIN (metadata jsonb_path_ops);
SELECT * FROM products WHERE metadata @> '{"category": "electronics"}';

-- MySQL: needs a functional index on the exact path to compete
ALTER TABLE products ADD INDEX idx_category ((CAST(metadata->>'$.category' AS CHAR(50))));
SELECT * FROM products WHERE metadata->>'$.category' = 'electronics';

MySQL isn’t hopeless here — its partial in-place JSON updates are cheaper on I/O than PostgreSQL’s, which tends to rewrite more of the row unless your indexes are narrow. But for anything involving deep nested lookups, flexible schemas, or search across JSON fields, PostgreSQL’s JSONB and GIN indexing is the clear winner. Use MySQL JSON only for shallow, single-key lookups where you’re not querying deeply into the structure.

What Breaks When You Migrate MySQL to PostgreSQL?

The biggest breakage points are auto-increment columns, case-sensitive string comparisons, and implicit type coercion — none of which map cleanly between the two engines. A straight `mysqldump` export will not import correctly into PostgreSQL; you need a translation layer, not a copy-paste.

1. Convert `AUTO_INCREMENT INT` columns to PostgreSQL `SERIAL` or `GENERATED ALWAYS AS IDENTITY` — the syntax is entirely different and unconverted dumps fail silently on import.
2. Audit every `WHERE` clause doing string comparisons — MySQL is case-insensitive by default (`utf8_general_ci`), PostgreSQL is case-sensitive unless you explicitly use `ILIKE` or a `citext` column.
3. Replace MySQL’s implicit type coercion (comparing a string column to an integer works fine in MySQL) with explicit casts, since PostgreSQL throws an error instead of silently converting.
4. Rewrite any `ON DUPLICATE KEY UPDATE` statements as PostgreSQL’s `INSERT … ON CONFLICT DO UPDATE` — this is the single most common migration failure I’ve seen in production.
5. Test date/time handling — MySQL’s `TIMESTAMP` silently converts time zones, PostgreSQL’s `timestamptz` requires you to be explicit about zone handling.

On a Laravel migration I ran last year, roughly 15% of the total migration time went into rewriting raw SQL queries that Eloquent’s query builder didn’t fully abstract — mostly reporting queries someone had hand-written for a performance boost on MySQL. Budget migration time in weeks, not days, for any application with more than a handful of raw queries, and run both databases in parallel with shadow writes before cutting over.

Which Database Costs Less to Run on AWS?

MySQL costs slightly less to run on AWS RDS and Aurora, but the gap is small enough that performance requirements should drive the decision, not price. Aurora PostgreSQL instances typically run 5-10% higher than equivalent Aurora MySQL instances for the same instance class, and PostgreSQL also generates more write I/O due to full-page writes and autovacuum, which adds to your I/O bill on I/O-optimized Aurora configurations.

For context, a small production Aurora cluster — one db.r6g.large writer plus one reader, 100GB storage, moderate I/O — runs roughly $400-600/month regardless of engine choice, with PostgreSQL landing at the higher end of that range. Graviton-based instances (db.r6g, db.r7g, db.t4g) offer up to 35% better price-performance than equivalent x86 instances on either engine, so that switch matters more than the MySQL-vs-PostgreSQL choice for your AWS bill.

Don’t let a 5-10% instance cost difference override a 4.9x write performance gap — the compute savings from running fewer or smaller instances on PostgreSQL’s better throughput usually outweighs the per-instance premium. Run the numbers for your actual workload rather than assuming MySQL is cheaper overall.

MySQL 8.4 vs PostgreSQL 17 — 2026 Snapshot for PHP Developers

Option	Performance	Complexity	When to Use
MySQL 8.4	20-30% faster simple reads; 4.9x slower writes than PostgreSQL	Low — huge ecosystem, simple ops	Drupal, WordPress, read-heavy legacy LAMP apps
PostgreSQL 17	4.9x faster writes, 3.7x faster JSON queries, 2.3x lower overall latency	Medium — more tuning knobs (autovacuum, GIN indexes)	New Laravel APIs, write-heavy apps, complex/JSON queries
MariaDB 10.3+	Comparable to MySQL, slightly better on some write paths	Low — drop-in MySQL replacement	Drupal’s officially recommended engine
Aurora MySQL	Matches MySQL 8.4 baseline plus Aurora storage scaling	Low-Medium — managed, fewer ops tasks	Teams wanting MySQL semantics with less DBA overhead
Aurora PostgreSQL	Matches PostgreSQL 17 baseline, 5-10% higher instance cost	Medium — managed, but more I/O to monitor	Write-heavy or JSON-heavy apps already committed to AWS

• PostgreSQL 17 sustained 21,338 inserts/sec versus MySQL 8.4’s 4,383 in 2026 sysbench testing — a 4.9x write performance gap.
• MySQL 8.4 outperforms PostgreSQL 17 by 20-30% on simple, read-only SELECT queries.
• PostgreSQL’s JSONB ran nested queries against 1 million documents at 12,600 QPS versus MySQL JSON’s 3,400 QPS — a 3.7x gap.
• Drupal 12 will require PostgreSQL 18+ if using that engine, but MariaDB remains Drupal’s officially recommended database across versions 10 through 12.
• Aurora PostgreSQL instances cost roughly 5-10% more than equivalent Aurora MySQL instances on AWS RDS.
• Migrating MySQL to PostgreSQL requires converting AUTO_INCREMENT to SERIAL, rewriting ON DUPLICATE KEY UPDATE as ON CONFLICT DO UPDATE, and auditing case-sensitive string comparisons — a straight mysqldump import will not work.

Frequently Asked Questions

Which is better, MySQL or PostgreSQL?

PostgreSQL is better for write-heavy, complex, or JSON-driven applications, winning writes by 4.9x and JSON queries by 3.7x in 2026 benchmarks. MySQL is better for simple, read-heavy workloads and remains the safer choice for Drupal and WordPress, where it wins reads by 20-30%.

Is PostgreSQL faster than MySQL?

PostgreSQL is faster for writes, mixed OLTP workloads, and complex or JSON queries, with a 4.9x write advantage and 2.3x lower overall latency in 2026 sysbench testing. MySQL remains 20-30% faster for simple, read-only SELECT queries.

Should I use PostgreSQL or MySQL for Laravel?

Use PostgreSQL for new Laravel projects — Eloquent works identically on both engines, and PostgreSQL’s JSONB, full-text search, and write performance benefit most non-trivial applications. Choose MySQL only if your team lacks PostgreSQL operational experience and the deadline is tight.

Does Drupal work with PostgreSQL?

Yes, Drupal core fully supports PostgreSQL, and Drupal 12 will require PostgreSQL 18+ if you choose that engine. However, MariaDB remains Drupal’s officially recommended database because most contributed modules are built and tested against MySQL/MariaDB first.

Can you migrate a MySQL database to PostgreSQL easily?

No, migrating MySQL to PostgreSQL is not a simple export-import — a straight mysqldump will not import correctly. You must convert AUTO_INCREMENT columns to SERIAL, rewrite ON DUPLICATE KEY UPDATE queries, and audit case-sensitive string comparisons before cutting over.

The MySQL vs PostgreSQL debate isn’t close anymore for write-heavy or JSON-driven PHP applications — PostgreSQL’s 2026 benchmark numbers are too large to hand-wave away. What surprised me most wasn’t the raw performance gap; it was how invisible the switch is at the Laravel layer versus how visible it becomes inside Drupal’s contrib module ecosystem. That asymmetry is the real decision variable most comparison posts skip. Pick PostgreSQL by default for new PHP work, keep Drupal on MariaDB unless you have the QA bandwidth to break from convention, and budget real migration time if you’re moving an existing app between the two.