Migrating your data
To move from MySQL to Postgres, you will need to:- Export your MySQL database (e.g., using
mysqldump
). - Use a tool like pgloader to import the data into your Serverless Postgres database.
Application implementation considerations
Keep in mind that although Postgres is very similar to MySQL, it is generally more strict in certain field definitions and usage. Below are common considerations which may be relevant to your application.MySQL | Postgres | Considerations | |
---|---|---|---|
Boolean Values | Stores as TINYINT | Stores as BOOLEAN | Boolean casting works in Laravel, but avoid direct 0 /1 comparisons in raw queries. |
Auto-Increment IDs | Uses AUTO_INCREMENT | Uses SERIAL | Laravel handles this with $table->id() or increments() , but raw SQL may need to be adjusted. |
Unsigned Integers | Supports unsignedInteger and unsignedBigInteger | Must use signed bigInteger / foreignId() | Although Laravel will silently handle conversions in your migration files, executing raw imports may reference UNSIGNED BIGINT columns. You will need to cast or redefine types on import. |
UUIDs | Stores as strings | Has native UUID support | If you have a custom UUID definition that does not match the specification, it will fail in Postgres. Use Laravel’s Str::uuid() helper to stay compatible. |
Zero Dates | Allows ‘0000-00-00’ | Invalid Date | Use nullable() and avoid “zero dates”; Postgres will throw an error. |
JSON Column | Supported, but is not validated. | Validates JSON on save. | Ensure the JSON you store is valid, else Postgres save will fail. |
Timestamp with Timezone | timestamp does not store timezone detail | Supports timestamp with and without timezone | Laravel defaults to timestamp , so you must explicitly use $table->timestampTz() if you want time zone-aware behavior. |
Implicit Foreign Key Indexes | Foreign key columns automatically receive corresponding index | Indexes are not automatically created | Explicitly add ->index() to any foreignId() columns to ensure indexes are created. |