Services
Move MySQL to PostgreSQL
MySQL can stay until the types, the queries, or the host stop fitting. PostgreSQL is the move when constraints should be strict and the rest of the stack needs room.
This is a data move, not a new product. The tables, the odd columns, and the report someone runs on Friday morning all have to arrive intact.
When it fits
- The types, the queries, or the host no longer fit MySQL.
- MySQL accepts rows that should have been rejected: zero dates, silent truncation, loose types.
- The data has to arrive intact, including the reports people run every week.
How the work goes
- We map types, indexes, and the queries the app actually sends.
- Unsigned integers, zero dates, and silent truncations are written down before anyone picks a cutover window.
- A rehearsal loads a copy into PostgreSQL and runs the app against it. Every query that had to change goes into the log.
- The cutover is a short freeze, a final copy, and a check that the counts and the money columns match. Rollback stays possible until that check passes.
Example: move a table
Cutover
Drag an item onto a row, or select it and use the Move buttons.
Drag orders from MySQL to PostgreSQL. The move is a copy, a check, then the switch.
MySQL
PostgreSQL
Move
What you receive
- A schema in PostgreSQL that rejects the bad rows MySQL used to store
- A rehearsal log with the queries that had to change
- A cutover you can schedule, and a way back if the counts disagree
How to start
Send the MySQL version, the application that talks to the database, and the reports that depend on it. Email it to info@developerlab.nl, or see the contact page for other ways to reach Puya Sarmidani.
Send an email