Why I moved my stack to Postgres — Nathan McBride Blog
Skip to content
Studio26 June 20264 min read

Why I moved my stack to Postgres

A small, obvious decision that I put off for six months. A note on pgvector, JSONB, and the boring case for the switch.

I had been on MySQL for a decade. It never broke. It never surprised me. It was boring in the exactly-good way a database should be. Which is why, for the best part of six months, I kept postponing the move to Postgres even though every new project was nudging me that way.

What actually pushed it over

pgvector. Not in a grand way — I have not been evangelising vector databases — but in an accumulating way. Two client briefs in a row asked for embedding search. The third had a PIM that wanted JSONB queries Postgres handles natively and MySQL fakes. At that point staying on MySQL was a habit, not a decision.

  • pgvector for embeddings, beside the product data, no second database
  • Native JSONB querying — no more JSON_CONTAINS-shaped gymnastics
  • Generated columns I actually trust
  • CTEs I already write in my sleep
  • A smaller gap between local, staging and Laravel Cloud production

What did not matter

Performance, at my scale, was a wash. Disk use went up slightly. Replication story is the same for me on Laravel Cloud. None of the "Postgres is faster" or "MySQL is faster" arguments applied at the volumes I run. The actual gain was a cleaner mental model for the kind of data I now handle — embeddings, JSON, structured content — not raw throughput.

PostgrespgvectorLaravelStudio