MySQL.
MySQL is behind 29 of the 30 projects I've shipped since 2017. That isn't loyalty — it's that a sensible default rarely deserves replacing: it's predictable, every host supports it, and any developer who follows me can read it. Most performance problems blamed on MySQL aren't MySQL's fault; they're missing indexes and N+1 queries in the application above it. That's usually where I start, and usually where it ends.
Predictable under real load
For the transactional workload most business applications actually have — reads, writes, joins over indexed columns — MySQL is fast, stable and unsurprising. Unsurprising is worth more than clever.
Everywhere, and cheap to run
Every host and every managed service supports it. No exotic infrastructure, no specialist DBA on retainer, no surprise bill for the privilege of storing rows.
Laravel-native
Eloquent, migrations and factories are written with MySQL as the assumed default. The schema lives in version control, and the same migrations run on a laptop and in production.
Honest performance tooling
EXPLAIN, the slow query log and index statistics tell you exactly what the database is doing. Most of my performance work is reading those carefully, not guessing.
The default, and it stays the default until something specific argues otherwise. Users, orders, invoices, reporting that fits in a query — MySQL handles it without ceremony.
I've built multi-tenant systems with a separate database per tenant on MySQL — clean isolation, simple backups, and a tenant can be exported or deleted without touching anyone else's data.
Old PHP systems are almost always already on MySQL. Keeping the database and rebuilding the application above it removes an entire category of risk from the project.
If you need real JSON querying, geospatial work or complex analytical queries, PostgreSQL is the better answer and I'll say so. MySQL will store JSON and answer analytical queries, but those aren't problems it solves well.
MySQL sits behind Eloquent and stays there — the application talks to models, not to SQL scattered through controllers. That boundary is what makes performance work possible later: when a page is slow there is one place to look, and the fix is usually an index or a missing eager load rather than an archaeology project.
Only if you have a reason — real JSON querying, geospatial, or heavy analytics. If your data is users, orders and invoices, Postgres won't make it faster, and MySQL is cheaper to host and easier to hire for. If you do have that reason, I'll tell you.
Almost never. Slow is usually the application: N+1 queries, missing indexes, work done in PHP that belongs in SQL. On one legacy rebuild a single page ran 3,982 queries; it now runs 52, on the same MySQL.
For the workloads I build, yes. Long before MySQL itself is the limit, the bottleneck is query and schema decisions — and those are fixable, far more cheaply than a migration.
In my work
MySQL is the database in 29 of my 30 projects since 2017 — including the multi-tenant platforms and the legacy rebuild where one page went from 3,982 queries down to 52.