laravel-mysql-to-postgres

Laravel: MySQL -> PostgreSQL migration

The data moves fine. What breaks is the assumptions your app baked in over the years, because MySQL is forgiving and Postgres is strict. Every place you leaned on MySQL being lenient is a bug waiting on the other side. Treat a migration as an audit of your app's lazy assumptions, not a data transfer.

Step 0 - The one test that surfaces half the problems

Before touching real data, point php artisan migrate at a fresh empty Postgres database and watch what throws. If every migration runs clean, your schema is genuinely database-agnostic. If it throws, you just found your MySQL-only assumptions for free.

# .env pointed at an empty pgsql db
php artisan migrate:fresh   # does the schema even build on Postgres?

Do not delete MySQL the day you switch. Keep it running for days/weeks until you're sure - cutovers get reverted.

Step 1 - Move the data (pick one)

• pgloader - a single tool built for exactly this. Reads MySQL, writes Postgres, converting types as it goes (TINYINT(1) -> boolean, AUTO_INCREMENT -> sequence). One command, most of the job. Usually resets sequences for you (see the trap below).
• Laravel's query builder - read from the old connection, write to the new one in PHP, transforming rows. More control, more code; good when the schema has corners pgloader trips on. Does NOT reset sequences - you must do it manually.

The behavior differences that silently break Laravel

1. Search stops matching (case sensitivity) - the big one for any app with search

MySQL's default collation is case-INsensitive; Postgres is case-SENSITIVE.

// Worked on MySQL ('iphone' matched 'iPhone'), silently returns nothing on Postgres:
Product::where('name', 'LIKE', "%{$q}%")->get();
// Fix - case-insensitive LIKE:
Product::where('name', 'ILIKE', "%{$q}%")->get();
// Heavy search: the citext extension, or a functional index on LOWER(name).

Audit every product search, "find by email", and user-typed filter.