PostgreSQL.
PostgreSQL is the database I reach for when the data asks for it, rather than when habit does. It's on my CV and on some of my projects; MySQL is on nearly all of them. That ratio is the honest picture, and it's a choice rather than a gap — where Postgres earns the switch is specific and easy to name: querying JSON properly, geospatial data, and analytical queries that would be a fight anywhere else.
Where it shines
JSON you can actually query
jsonb is a real, indexable type — you can query inside a document, index the path, and keep it fast. If your data is genuinely semi-structured, this alone justifies Postgres.
Geospatial that works
With PostGIS, "everything within 5km, nearest first" is an indexed query rather than a pile of application code doing trigonometry badly.
Analytical queries
Window functions, CTEs and a stronger planner keep reporting queries in the database, where the data already is, instead of being assembled row by row in PHP.
Strict by default
Stricter typing and constraints mean Postgres refuses bad data rather than quietly coercing it. On a complex domain that catches problems on the write, not in a report months later.
When documents are the data rather than a convenience column — variable shapes you still need to filter, sort and index on — jsonb is the feature worth switching for.
Distances, boundaries, and "what is near this point" belong in PostGIS. Approximating that in application code is slower to build and slower to run.
When the product itself has to answer analytical questions, Postgres keeps that work in SQL instead of dragging every row into PHP to be counted.
If the workload is ordinary CRUD and you're already on MySQL, Postgres buys you nothing you can measure and costs you a migration. I default to MySQL for a reason: the switch has to be argued for, not assumed.
Postgres slots into the same architecture as MySQL: Laravel owns the domain logic, Eloquent owns the schema, and the engine is a decision made once, early, on the merits of the data. Because Eloquent abstracts most of the difference, choosing Postgres is not a rewrite — it is configuration, migrations, and the specific features you chose it for.
Fair question, and the honest answer is that across the case studies on this site, MySQL is on 54 and Postgres on 4. It's on my CV because I've shipped with it, not to fill a page. What carries across is the part that matters most: schema design, indexing and query performance are the same discipline on either engine.
"Postgres is better" is not a reason. If you need jsonb, PostGIS or serious analytical queries, that is a reason and the case makes itself. A migration costs real time and carries real risk, so it should buy something you can name.
Look at the data, not the trend. Users, orders and invoices: MySQL, and spend the saved effort on the product. Semi-structured documents, maps, or analytics baked into the product: Postgres from day one — starting there is far cheaper than moving later.
In my work
I use PostgreSQL on the projects whose data calls for it, and MySQL on the rest — 4 case studies on this site run on Postgres, the majority on MySQL. The choice gets argued on the data, never on preference.