Data platform · MySQL to PostgreSQL

MySQL to PostgreSQL migration, with MySQL kept in sync until cutover

A MySQL to PostgreSQL migration looks easy because both are open source relational databases. The work hides in the details: unsigned integers, zero dates, character sets that hold Arabic text in unexpected ways, AUTO_INCREMENT keys and SQL that PostgreSQL refuses. Interkey runs the move from Riyadh, and iblync, its own replication platform, keeps MySQL and PostgreSQL in step until the checks pass.

Plan your MySQL to PostgreSQL cutover How the data types map

MySQL to PostgreSQL migration at a glance

The main facts of a MySQL to PostgreSQL migration with Interkey
Question	Short answer
Why teams move	One engine to run, PostgreSQL features such as stricter types, or a managed PostgreSQL service
What moves	Schema, data, routines, triggers, events and the application queries that rely on MySQL behaviour
Where the effort sits	Usually in data quality, character sets and application SQL, not in the copy itself
How the outage is kept short	Initial load, continuous sync with iblync, a parallel run, then a cutover in gated steps
Where it runs	The replication bridge, the target database and the tooling can run on infrastructure inside the Kingdom
How it is priced	Per engagement after an assessment; iblync by quotation, per source system, target system and data volume

For an executive: this move rarely saves licence fees, so the case rests on what the business gains. The assessment states that gain, and may advise staying on MySQL.

When a MySQL to PostgreSQL migration makes sense

Teams that ask us to migrate MySQL to PostgreSQL usually have one of three reasons. They want one engine across their systems, run, backed up and monitored the same way. They need something PostgreSQL does well, such as strict types, indexed JSON or geographic extensions. Or a managed PostgreSQL service has been chosen and MySQL has to follow.

It is worth doing when the gain is named and someone will run PostgreSQL afterwards, not to fix a performance problem that tuning MySQL would solve. If that is the honest answer, we say so in writing. The general method for any source is on our PostgreSQL migration page; this page is about the MySQL source specifically.

Convert MySQL to PostgreSQL: how the data types map

Common MySQL data types and their usual PostgreSQL equivalents
MySQL	PostgreSQL	What to check
INT, BIGINT, SMALLINT	integer, bigint, smallint	Usually a direct match
INT UNSIGNED	bigint	PostgreSQL has no unsigned integers; the wider type holds the full range
TINYINT(1)	boolean or smallint	Often a yes/no flag; comparisons with 1 and 0 change if it becomes boolean
AUTO_INCREMENT	GENERATED AS IDENTITY	Set the next value after the load; see the note below
DATETIME	timestamp	Zero dates such as 0000-00-00 are not valid in PostgreSQL; decide NULL or a real value
TIMESTAMP	timestamptz	MySQL converts TIMESTAMP values by the session time zone; confirm which zone the stored values assume
VARCHAR(n), TEXT, MEDIUMTEXT, LONGTEXT	varchar(n) or text	Check the character set of each column first
ENUM	an enum type, or text with a check constraint	Adding a value later is easier with text and a constraint
SET	text[] or a link table	A design decision; queries that use FIND_IN_SET change
JSON	jsonb	Indexable; key order and duplicate keys are not kept

A MySQL to PostgreSQL converter can draft this mapping; the right-hand column is reviewed by hand.

AUTO_INCREMENT in practice. A PostgreSQL identity column draws from a sequence. When rows are loaded with their original keys, the sequence still starts at one, so the first new insert collides. Each sequence is set past the highest loaded value, again at cutover. Applications that insert 0 or NULL to get a new key also change.

Character sets, collations and Arabic text

This part most often surprises a Saudi team, because it touches Arabic names, addresses and free text.

utf8 is not always full UTF-8. In MySQL, the character set called utf8 is a three-byte form that cannot store some characters, such as many emoji; utf8mb4 is the full form. PostgreSQL's UTF8 is complete, but characters MySQL already dropped are gone.
Arabic stored in a latin1 column. Older applications sometimes wrote UTF-8 bytes into latin1 columns: the text looks right in the application and wrong everywhere else. The assessment samples every text column to find this, and the conversion is fixed per column.
Invalid bytes. PostgreSQL rejects byte sequences that are invalid in its encoding, so a failed row shows where dirty data is.
Case and accents. MySQL's default collations usually ignore case, so 'Riyadh' equals 'RIYADH'; PostgreSQL compares text exactly by default. Unique keys and searches on text need a decision: a lower-case index, the citext extension, or a case-insensitive collation.
Lenient modes. Without strict mode, MySQL can adjust invalid values and store them with a warning. PostgreSQL raises an error, so the migration brings them to light.

Arabic searches that relied on MySQL's collation are retested with your own data.

SQL and code that usually needs rework

Most MySQL applications keep their SQL in the application, not the database. The changes are small but spread across many files:

Quoting. Backticks become double quotes or disappear; PostgreSQL folds unquoted names to lower case.
Upserts and keys. INSERT ... ON DUPLICATE KEY UPDATE becomes INSERT ... ON CONFLICT ... DO UPDATE, and LAST_INSERT_ID() is replaced by RETURNING.
Paging and functions. LIMIT 20, 10 becomes LIMIT 10 OFFSET 20, and IFNULL becomes COALESCE. In MySQL, || usually means OR; in PostgreSQL it joins strings.
GROUP BY. MySQL can allow selecting columns that are neither grouped nor aggregated; PostgreSQL refuses unless they depend on the grouped primary key.
Division. In MySQL, 5 / 2 returns 2.5; in PostgreSQL, integer division returns 2. Test financial reports.
Procedures, triggers and events. Routines are rewritten in PL/pgSQL, triggers become trigger functions, and event scheduler jobs need a new scheduler.

Our engineers find these by reading the code and running the application's tests on PostgreSQL, before anyone quotes a duration.

Migrate MySQL to PostgreSQL with continuous sync during cutover

iblync is Interkey's own data migration and replication platform, and MySQL and PostgreSQL are both on its published connector list. Here it moves the data and keeps the two databases in step while the rest is proved.

Initial load. The data is copied once, throttled so it does not compete with production. iblync's site states that an interrupted migration resumes where it left off.
Continuous sync. Every MySQL change after the load is applied to PostgreSQL with the same type and character-set rules; if PostgreSQL is unavailable, changes queue instead of failing. The assessment checks MySQL's logging settings, which decide how changes are read.
Two-way where needed. iblync supports bi-directional synchronisation, so some services can write to PostgreSQL while others still write to MySQL, and changes can flow back for an agreed period to keep a rollback open.
Proof. iblync's own site states that validation uses checksums and row counts. The pass conditions for your data are agreed before cutover.

Where it does not fit: iblync does not rewrite SQL or change your application; our engineers do that with your teams. More on the streaming itself is on our real time replication page.

Relatedreal time replication page

How a MySQL to PostgreSQL project runs

Assessment.

Versions, schema, character sets and collations, sql_mode, routines, application SQL, volume, change rate, downtime window and residency. The output is a decision, including staying on MySQL.
Schema and data quality.

Types are mapped, encoding problems and invalid values fixed per column, and the schema tested on production-shaped data.
Application changes.

Drivers and queries are changed and tested per service, with your application teams.
Load and sync.

iblync loads the data and keeps PostgreSQL in step with MySQL.
Parallel run.

Both databases live; reads move first, service by service, in steps that can be reversed.
Gated cutover.

Writes pause, the final sync drains, counts and checksums are compared, sequences reset, then writes move. Both cutover and rollback are rehearsed.
Stabilise and hand over.

Tuning, backup-restore proof and failover drills, then handover to your DBAs or to Interkey.

What Interkey delivers in Saudi Arabia

One team for the assessment, conversion, replication and cutover, with support from Riyadh in Arabic and English. The replication bridge, the target database and the tooling can run on infrastructure inside the Kingdom, which matters when the data is personal or regulated; residency is settled before any copy is made.

Before you start, our migration decision checklist covers whether the move is worth it. If your estate also runs SQL Server, the SQL Server to PostgreSQL page covers that source.

What drives the cost

Quotes are per engagement, after the assessment. The drivers are the number of servers, how clean the data and character sets are, how much application SQL changes, data volume and change rate, the downtime window, the deployment model, and who runs PostgreSQL afterwards. iblync itself is priced by quotation, per source system, target system and data volume.

Questions buyers ask

MySQL has no licence fee either, so what does a move to PostgreSQL actually save us?

Usually not licence fees, unless you pay for a commercial MySQL edition. The gain is one engine to run, or PostgreSQL features your teams need; the cost is the migration itself. The assessment weighs the two.

How long would a MySQL to PostgreSQL migration take for a company in Saudi Arabia?

It depends on data quality, the application SQL that changes, data volume and the downtime window. We give a range after the assessment, with what moves it named.

Will Arabic text stored in MySQL come across to PostgreSQL correctly?

If it is stored correctly in MySQL, yes. The risk is older columns that hold Arabic in the wrong character set; the assessment finds them and each gets its own conversion rule.

What happens to our AUTO_INCREMENT keys after the move?

They become identity columns that keep their values. Each sequence is set past the highest loaded key, and again at cutover, so new rows do not collide with old ones.

Can our MySQL application keep running while PostgreSQL is loaded and tested?

Yes. iblync loads the data, then applies every MySQL change to PostgreSQL continuously. Writes move only when the agreed checks pass, after a short pause for the final sync.

Can the migration servers and the new PostgreSQL database be hosted inside the Kingdom?

Yes. The replication bridge, the target database and the tooling can run on infrastructure inside the Kingdom. Residency and access are agreed before the first copy.

Next step

Plan your MySQL to PostgreSQL cutover

Tell us the MySQL versions and servers, the rough data volume, the character sets in use, how many applications connect, and the downtime window you can accept.

First name Last name

Company Email Company

Phone number (optional) What are you working on? (optional)

Required field

By sending this form, you agree to our Privacy Notice.

Published by Interkey. Last updated 2026-11-10. Interkey is registered in Riyadh, Saudi Arabia under commercial registration 1010156897.

Assessment.

Schema and data quality.

Application changes.

Load and sync.

Parallel run.

Gated cutover.

Stabilise and hand over.

Plan your MySQL to PostgreSQL cutover