Eric runs data at a UK growth-stage SaaS. MySQL 5.7. A 480GB database. 2,200 transactions per second at peak. Reports had started taking 90 seconds and blocking the write path.
Migration MySQL to PostgreSQL migration · zero-downtime cutover · UK
MySQL to PostgreSQL migration with a rehearsed rollback. not an 11-hour outage.
We move UK SaaS and fintech teams off MySQL onto PostgreSQL — logical replication for a zero-downtime cutover, stored procedures ported to plpgsql, JSON remodelled into JSONB, and the rollback rehearsed before we touch production.
5MySQL → Postgres migrations shipped
0sdowntime via logical replication
8K5-day fixed-scope audit
Why CTOs migrate now
You don’t need to leave MySQL. You need to leave the version of it that’s costing you growth.
A MySQL to PostgreSQL migration isn’t a religion. It’s the moment JSON queries, long-running reports, and the AI feature you want all point the same way. We make the risks legible before a single line of production code changes.
“Cutover happened in a 90-second window at 4am Saturday. Reports dropped from 90 seconds to under four. We shipped the AI feature two weeks later.”
001
5
MySQL to Postgres migrations shipped since 2019.
002
90s
Largest cutover window, on a 480GB estate.
003
0
Production rollbacks we’ve had to execute.
The CTO this page is for480GB · 2,200 TPS · 11h outage once
Eric’s first migration attempt took the site down for 11 hours.
JSON column queries went to full table scans. Two stored procedures had race conditions nobody could reproduce. The team wanted pgvector for the new AI feature. So they tried a mysqldump-based migration over a weekend. It took the site down for 11 hours and got rolled back.
Twelve weeks later we cut over in a 90-second window at 4am on a Saturday, with reverse replication staged for rollback. Reports dropped from 90s to under 4s. This page is for the CTO who has decided the migration is happening, and wants it to land without taking the business down.
Our zero downtime postgres migration process
Four migration phases
No mystery box. Each phase is fixed-scope, fixed-price, and ends with a written deliverable you can show your board. You decide whether to continue at every boundary.
Phase 01 · 5 days · £8K
Migration audit
Two senior engineers read your MySQL codebase, data, and infra. Output: a 20-30 page audit pack with risk matrix, target architecture, data plan, rollback plan, and a fixed quote.
Phase 02 · 2-4 weeks
Plan + parallel build
We build the Postgres target in parallel while MySQL keeps running. Data dry-runs. Integrations rebuilt. Dual-write or shadow-read set up. No customer-facing change yet.
Phase 03 · 1-3 days
Planned cutover
Cutover in a planned window, often a weekend. Dual-run, shadow-read, then flip the canonical write path. Old system stays read-only for 30 days. Rollback rehearsed.
Phase 04 · 2-6 weeks
Stabilise + decommission
We fix what only production traffic surfaces, hand over to your team, and decommission the old MySQL estate on a schedule you sign off. Nothing deleted until you say it can be.
The stack we migrate you onto.
We default to Postgres 16 on AWS with the migration tooling that makes a zero-downtime cutover real. We substitute where your team has constraints or an existing relationship.
T1
The default Postgres target
Postgres 16PostgreSQL 16PgBouncerPrisma / TypeORM / SQLAlchemyNode.js + PythonReact + Next.jsPostGISpgvectorTimescaleDBpg_partmanpg_cronPatroniAWS RDS Multi-AZ
T2
Migration-specific tooling
cutover kitpgloaderDebezium + KafkaAWS DMSpg_dump + pg_restorepgBadgerlogical replication slots
T3
Infrastructure, observability + safety net
AWS-defaultAWS RDS PostgresAWS Aurora PostgresS3 + WAL archive (PITR)CloudWatch + DatadogTerraformSentrypg_repackpgwatchk6 / pgbenchGitHub Actions
Risk + mitigation matrix
The risks that sink a MySQL to Postgres migration. How we close each one before cutover
We don’t pretend migrations are safe. We make each risk legible and mitigated, in writing, before a single line of production code changes.
Type system gaps
AUTO_INCREMENT becomes sequences. TINYINT(1) becomes BOOLEAN. ENUM becomes a CHECK or lookup table. DATETIME becomes TIMESTAMPTZ. Every column mapped at audit.
Stored procedures and triggers
MySQL procedure syntax doesn’t port. We rewrite in plpgsql with explicit transaction control, or extract to application code, and test against MySQL output.
JSON modelling
Postgres JSONB is indexed and queryable. We remodel where JSON is queried, add GIN indexes, and rewrite queries to JSONB operators. 10 to 100× faster.
Zero-downtime cutover
We catch the replication delta to zero in a maintenance window, flip the connection string, and keep MySQL replicating from Postgres in reverse for 24 hours as rollback insurance.
Index and planner regressions
We rebuild indexes and run EXPLAIN against the top 50 queries pre-cutover. Slow query logs compared. No regressions ship to production.
Rollback you can trust
Postgres to MySQL reverse replication is staged before cutover. Rollback is a connection-string change executable in under five minutes, not a recovery operation.
Results
MySQL 5.7 to Postgres 16,
MySQL 5.7 to Postgres 16,
Eric’s migration, in numbers
Brief: leave MySQL for JSONB, pgvector, and reporting performance. Twelve-week migration. Schema ported, procedures rewritten in plpgsql, JSON remodelled as JSONB with GIN. Logical replication for 6 weeks. Cutover in a 90-second window with reverse replication staged for rollback.
The cutover
90s
Maintenance window, 4am Saturday
480GB
Database migrated
Performance
90s4s
Reports, after the move
2 wks
To ship the pgvector AI feature
Track record
5
MySQL Postgres migrations since 2019
0
Production rollbacks executed
Audit, then sprint. Pricing in the email back.
Pick the shape that fits and Mohit will send your real number inside 24 hours.
5-day migration audit
Two senior engineers read your MySQL estate, data, and integrations. Map the migration. Write the risk matrix. Quote the sprint.
- 5-day senior audit
- Risk matrix + target architecture
- Data + rollback plan
- £8,000 fixed, no commitment to build
PostgreSQL migration sprint
Parallel build, dry-run data migration, planned cutover, post-cutover stabilisation, decommission. 8-16 weeks by estate size.
- Logical replication or CDC cutover
- Two senior engineers
- 30-day walk-away both ways
- From £35,000 fixed
Post-migration retainer
One day a week of senior engineering for 3-6 months. New surface area, performance work, integrations. Your team gets unblocked.
- One senior day / week
- Performance + index tuning
- Integration work
- From £5,000 / month
“Cutover happened in a 90-second window at 4am Saturday. Reports dropped from 90 seconds to under four. We shipped the AI feature two weeks later.”
— Eric, Head of Data, UK growth-stage SaaS
Zero downtime postgres migration · honest answers
What CTOs actually ask on the audit call
Pain-first, soft-second. Click each one to open it.
Q(01)
How do you achieve zero downtime on a database migration?
Logical replication, or Debezium / AWS DMS for change-data-capture, keeps Postgres in sync with MySQL for weeks before cutover. At cutover we catch the replication delta to zero, flip the application connection string in a 60 to 90 second window, and keep MySQL replicating back from Postgres as rollback insurance for 24 to 72 hours.
Logical replicationDebezium / DMS60-90s window
How do you achieve zero downtime?
Q(02)
What happens to our stored procedures and triggers?
Rewritten in plpgsql. We test parity against the MySQL output for every input set. Sometimes we extract the logic to application code instead, because it’s easier to test, version-control, and observe. Either way, nothing ships without a parity test.
plpgsqlParity testedApp-code option
What happens to our stored procedures?
Q(03)
How do you handle our JSON columns?
Remodelled as JSONB with GIN indexes where the columns are queried. Queries that were full scans on MySQL JSON typically become indexed lookups on Postgres JSONB. 10 to 100× faster is normal, and it’s usually the reason the move pays for itself.
JSONBGIN indexes10-100× faster
How do you handle our JSON columns?
Q(04)
What if the cutover goes wrong?
We rehearse. Reverse replication, Postgres to MySQL, is set up before cutover. Rollback is a connection-string change, executable in under five minutes. We’ve never had to roll back in production across five migrations, but the rehearsal is non-negotiable.
Reverse replicationUnder 5 minRehearsed
What if the cutover goes wrong?
Q(05)
Our last attempt took the site down for hours. How is this different?
A mysqldump-and-restore migration locks the database for the length of the restore. On 480GB that’s hours. We don’t do that. We replicate continuously for weeks, then cut over in a sub-90-second window once the delta is zero.
No dump-restoreContinuous syncSub-90s
How is this different from our last attempt?
Q(06)
How do you price a migration, and how long does it take?
The audit is £8,000 fixed for 5 days. The migration sprint is from £35,000 fixed, 8 to 16 weeks depending on estate size. You see both numbers before you commit to the build. No day-rate, no scope creep billed back to you.
£8K auditFrom £35K8-16 weeks
How do you price a migration?
In context
Inside the work.
A look at the kind of mysql to postgresql migration surface we hand over — real screens, real data, documented and yours from day one.
Five lines. That’s it.
Tell us your current MySQL estate (traffic, data size, integrations), why you want to migrate, and the deadline you’re working to. Mohit replies inside 24 hours: availability and the next 5-day audit slot.
What happens after the email lands
- < 24h
A personal reply.
Availability and the next 5-day audit slot. Straight to your inbox.
- Week 1
Migration audit begins.
Risk matrix, target architecture, data plan, rollback plan, fixed quote.
- Cutover
Sub-90-second window.
Logical replication catches the delta to zero. Reverse replication staged.