Every few months someone on the internet declares that PostgreSQL is the only serious database and MySQL is for people who don't know better. A few days later, someone else points out that a huge share of the web runs happily on MySQL and always has.

Both camps are partly right, and neither helps you choose a database for your next Laravel project on a Tuesday afternoon.

So let's skip the tribal part and the benchmarks. I work mostly with MySQL, and I like PostgreSQL a lot. Here's where the two genuinely differ in ways a Laravel developer will feel, and how I'd decide.

First, the good news

For a typical Laravel app (users, orders, invoices, contracts, a few reports) both are excellent. Eloquent, migrations, the query builder, queues and sessions all work the same on either. If you write normal Laravel code, you can build the whole app without touching anything database-specific.

Both are mature, transactional, fast for this kind of workload, and available as managed services on every major cloud (on AWS, RDS offers both). Neither choice will sink a project. The differences show up at the edges, and the edges are where your specific project lives.

At a glance

Where PostgreSQL pulls ahead

JSON you actually query

Both databases store JSON, and Laravel's whereJsonContains and -> path syntax work on both. The difference is indexing. In MySQL you typically index a specific JSON path through a generated column or a functional index, which is fine when you know the paths in advance. Postgres's jsonb with a GIN index can make containment queries fast across the whole document. If JSON columns are central to your design rather than a side detail, Postgres is more comfortable.

Extensions

This is Postgres's biggest advantage. PostGIS for serious geospatial work. pgvector for storing embeddings and running similarity search next to your normal data, which has become very relevant for AI features. pg_trgm for fuzzy text matching. With MySQL, some of those needs mean adding another service.

Safer migrations and smarter indexes

Transactional DDL means a migration that fails halfway can roll back cleanly instead of leaving a half-changed schema. Partial indexes let you index just the rows you query, like WHERE deleted_at IS NULL, or enforce "only one active contract per unit" with a unique index on a subset of rows.

Where MySQL is the easier choice

• Familiarity and ecosystem. Most PHP developers have years of MySQL experience. Most tutorials, hosting panels, backup scripts and admin tools assume it.
• Operations. Postgres needs a little more understanding to run well: vacuuming, connection limits (a pooler such as PgBouncer is common at scale). Managed services handle much of this, but someone on the team should understand it.
• Forgiving text comparison. Case-insensitive matching by default is usually what business apps want for names and emails.
• Existing systems. If your other apps, reports and integrations already use MySQL, one engine across the company is a real advantage.

Gotchas when switching between them

These are the ones that bite Laravel apps moving from one to the other:

• Case-sensitive LIKE. On Postgres, where('name', 'like', '%sara%') won't match "Sara". Use whereLike('name', '%sara%'), which is case-insensitive by default and generates the right SQL for each database.
• Stricter types. Postgres refuses comparisons MySQL would quietly coerce, like a string against an integer column. Good discipline, but expect a few errors in older code.
• Upserts. Laravel's upsert() on MySQL and MariaDB ignores the "unique by" columns you pass and uses the table's primary and unique indexes. Postgres needs a unique index on exactly those columns. Code that works on one can fail on the other.
• Raw SQL. DB::raw() with MySQL-only functions (DATE_FORMAT, GROUP_CONCAT, IFNULL) needs rewriting. Search for them before you estimate a migration.
• Enum columns. On Postgres, Laravel implements enum() as a string column with a check constraint, not a native enum type. Usually fine; just know it.

How I'd decide

Choose PostgreSQL when:

• you'll query JSON heavily, need geospatial queries, or want vector search inside your main database
• data integrity rules benefit from partial unique indexes and stricter typing
• the team knows Postgres, or is keen to learn it properly

Choose MySQL when:

• the team and the company's existing systems already run on it
• the app is a classic business CRUD system with relational data and reports
• you want the most widely understood, widely hosted option

And when none of those apply strongly? Pick the one your team can operate confidently at 2 a.m. Backups, restores, upgrades, slow-query investigation: that knowledge matters more than any feature in the table above.

The short version

• For typical Laravel apps, both are excellent.
• Postgres wins on extensions, jsonb, transactional DDL and partial indexes.
• MySQL wins on familiarity, ubiquity and forgiving defaults.
• Team familiarity is a legitimate technical reason, not a cop-out.

What does your team run, and what would make you switch? I'm curious whether pgvector has tipped anyone towards Postgres for AI features.