Cost to migrate from MySQL to Postgres

Migrating from MySQL to PostgreSQL in 2026 typically costs $2,000 to $24,000 in engineer time depending on database size and application coupling. A sub-100GB database with a clean ORM costs 2 to 4 engineer-weeks. A 100GB to 1TB database with raw SQL spread across services costs 6 to 12 weeks. Anything over 1TB with live cutover requirements lands at 12+ weeks.

The migration cost is almost never the database itself. It's schema translation, application code rewrites, and the live cutover dance. Tooling (pgloader, AWS DMS, Debezium) handles the bytes. Engineers handle everything around them.

What actually drives the cost

Three variables decide whether your migration takes 2 weeks or 4 months:

• Database size and complexity. Row count matters less than table count, foreign-key depth, and how many stored procedures you wrote. A 500GB database with 30 tables and zero stored procs is easier than a 50GB database with 400 tables and Perl-style triggers.
• How coupled your application is to MySQL syntax. ORMs (Prisma, Drizzle, ActiveRecord, Django ORM, SQLAlchemy) abstract most differences. Raw SQL strings, MySQL-specific functions (GROUP_CONCAT, STR_TO_DATE, backticks), and case-insensitive identifier quirks all need code-level fixes.
• Downtime tolerance. A weekend maintenance window costs a fraction of a zero-downtime live cutover with dual writes, replication lag monitoring, and rollback plans.

Most teams underestimate the second variable. The schema diff is mechanical. Hunting down every ON DUPLICATE KEY UPDATE across a 5-year codebase is not.

Schema translation: where the syntax actually differs

Postgres and MySQL look similar at first glance. They diverge in a dozen small ways that all bite you on cutover day.

MySQL pattern	Postgres equivalent	Notes
AUTO_INCREMENT	GENERATED ALWAYS AS IDENTITY or SERIAL	Sequences are first-class objects in Postgres
TINYINT(1) for booleans	BOOLEAN	True boolean type, not 0/1 integer
DATETIME	TIMESTAMP or TIMESTAMPTZ	Postgres has real timezone-aware timestamps
JSON	JSONB	JSONB is binary, indexed, and queryable; almost always what you want
ENUM('a','b')	CREATE TYPE enum or CHECK constraint	Postgres enums are types, not column-level lists
utf8mb4 charset	UTF-8 by default	Postgres skips the MySQL utf8 vs utf8mb4 trap
ON UPDATE CURRENT_TIMESTAMP	Trigger or app-level	Postgres has no equivalent column attribute
Backticks for identifiers	Double quotes	Case sensitivity rules also flip
LIMIT 10, 20 (offset, count)	LIMIT 20 OFFSET 10	Argument order is reversed
IFNULL(a,b)	COALESCE(a,b)	Different function name
GROUP_CONCAT	STRING_AGG	Same idea, different signature

The biggest unforced error: assuming JSON and JSONB are interchangeable. Postgres JSONB is the reason most teams want to migrate. It supports GIN indexes, path operators (->>), and containment queries (@>). Use it.

The second biggest: ignoring ON UPDATE CURRENT_TIMESTAMP. MySQL gives you a free "updated_at" auto-update. Postgres makes you write a trigger or set the column in your application's update statement. Forgetting this leads to silently stale updated_at values for months.

Migration tooling: what to actually use

The tooling has consolidated. Most teams pick one of four paths:

• pgloader. Open source, free, handles small to medium databases (under 500GB) in one shot. The fastest path from MySQL dump to Postgres-loaded. Schema conversion is built-in but sometimes opinionated; check the casts.
• AWS DMS (Database Migration Service). Managed, supports continuous replication for live cutover, ~$0.20/hour for the smallest replication instance. Good if both source and target live in AWS RDS. Schema conversion via the AWS Schema Conversion Tool (SCT) is free.
• Debezium + Kafka. Open source CDC (change data capture). Read MySQL's binlog, stream to Kafka, write to Postgres. Most flexibility, most operational overhead. Pick this if you need a permanent dual-write pipeline.
• Bytebase or Spliceflow. Managed migration platforms with schema review, rollout, and rollback baked in. Useful for teams that want a UI and audit trail rather than a script.

For most teams under 1TB with a maintenance window, pgloader plus a 1-hour cutover is the right answer. For zero-downtime over 1TB, AWS DMS if you're on AWS, Debezium if you're not.

Application code: the hidden cost

The schema translation is one engineer-day. The application changes are everything else. Common gotchas:

• Case sensitivity. MySQL is case-insensitive by default. Postgres treats User and user as different identifiers. Every unquoted table name, column name, and string comparison needs an audit.
• GROUP BY strictness. MySQL lets you SELECT a, b FROM t GROUP BY a and silently picks a value for b. Postgres rejects this query. Every non-aggregated column needs to appear in GROUP BY or be wrapped in an aggregate.
• Empty string vs NULL. MySQL often coerces empty strings to NULL in nullable columns. Postgres keeps them as empty strings. Validation logic that checks IS NULL will silently break.
• MySQL-specific functions. GROUP_CONCAT, IFNULL, STR_TO_DATE, FROM_UNIXTIME, DATE_FORMAT. All have Postgres equivalents with different names and slightly different behavior.
• Reserved words. user, order, group are reserved in Postgres. If you have a users.user column, every query needs quoting.

If your codebase uses an ORM (Prisma, Drizzle, SQLAlchemy), most of this is handled. Work shrinks to raw queries, custom database functions, and migration scripts. If your codebase has raw SQL strings spread across services, budget 2x to 3x the schema translation time for application changes.

The live cutover pattern

Zero-downtime migration is the most expensive part. The shape:

1. Set up replication. Use Debezium or AWS DMS to replicate MySQL writes to Postgres in real time. Lag should stay under 5 seconds.
2. Backfill historical data. Run an initial dump-and-load (pgloader works) before enabling CDC. CDC handles deltas from there.
3. Dual-write from the application. Modify your write path to write to both MySQL (primary) and Postgres (shadow). Compare results asynchronously. Catch translation bugs before cutover.
4. Shadow reads. Route a small percentage of read traffic to Postgres. Compare row counts and result hashes. Fix discrepancies.
5. Cutover window. Brief read-only mode (60 to 300 seconds), wait for replication lag to hit zero, flip the connection string, re-enable writes. Monitor for 24 hours.
6. Rollback plan. Keep MySQL warm with reverse replication for at least a week. If Postgres misbehaves, flip back. The reverse replication is the insurance policy that lets you sleep.

This dance adds 4 to 8 weeks. Most teams don't need it; if you can take a 2-hour Sunday-morning window, skip everything except steps 1, 2, and 5.

Validating the migration

Three checks that catch 95% of bugs:

• Row counts per table. Trivial, but the first thing to break if your CDC pipeline drops events.
• Checksum every row. SELECT md5(string_agg(t::text, '')) FROM (SELECT * FROM table ORDER BY id) t. Run on both sides, compare. Slow on large tables; sample 10% if needed.
• Application-level invariants. Run your test suite against Postgres. Then run a read-only diff of production traffic for 24 hours. Anything that returns different results between MySQL and Postgres is a bug, usually a GROUP BY strictness issue.

Skip validation and you'll discover the bug 3 weeks after cutover when a customer reports a missing record. Don't skip validation.

Cost breakdown by approach

Real engineer time, real cost, real trade-offs.

Approach	Cost	Timeline	Pros	Cons
In-house senior engineer	$8,000–$24,000 (loaded cost)	4–12 weeks	Owns the system long-term; full context	Senior engineers are expensive; opportunity cost on roadmap
US dev agency	$30,000–$120,000	6–16 weeks	Process and accountability	Slow ramp-up; high markup; weak ownership post-handoff
Toptal contractor	$10,000–$40,000	4–12 weeks	Vetted senior talent; flexible	Hourly billing; slow vetting (1–2 weeks to start)
AWS Professional Services	$50,000–$200,000	8–20 weeks	Deep AWS DMS expertise; enterprise sign-off	Expensive; AWS-only solution path
Upwork freelancer	$1,500–$10,000	3–10 weeks	Cheap; fast to hire	Quality variance is high; rollback discipline often missing
Cadence	$1,500–$8,000 (1–4 weeks at senior tier)	48-hour trial, ship in 2–8 weeks	AI-native engineers (Cursor, Claude Code daily); weekly billing; replace any week	Less suited to enterprise procurement gates

The math: a senior Cadence engineer at $1,500/week, working 4 weeks on a 200GB migration, costs $6,000 total. The same migration at a US agency typically lands at $50,000+. The agency markup pays for project management, not migration speed.

Why teams migrate (and when not to)

The honest case for migrating:

• JSONB. If you're querying JSON heavily (feature flags, user preferences, event payloads), Postgres JSONB with GIN indexes is genuinely faster than MySQL JSON.
• Row-level security (RLS). If you're building multi-tenant SaaS and want database-enforced tenant isolation, RLS is a Postgres-only feature that eliminates a class of bugs.
• Extensions. PostGIS for geospatial, pgvector for embeddings, TimescaleDB for time-series, pg_cron for scheduled jobs. MySQL has nothing comparable.
• Window functions and CTEs. MySQL added these recently and they work, but Postgres has had them longer and the planner is better at them.
• Generated columns and partial indexes. Postgres handles these more flexibly.

The honest case for not migrating:

• Your MySQL stack works fine. If you're running MySQL on RDS, you have read replicas, your queries are tuned, and nothing on the roadmap needs Postgres-specific features, the migration is a 2-month distraction. Spend the engineer-weeks on customer features instead.
• You depend on MySQL-specific tooling. Vitess, ProxySQL, Percona Toolkit, MyRocks. The Postgres ecosystem has equivalents but they're not drop-in replacements.
• Your team is MySQL-fluent. Operational knowledge (backup, replication, monitoring, query tuning) doesn't transfer. Budget 4 to 8 weeks of learning curve on top of the migration itself.
• You're pre-product-market-fit. If you're still figuring out what the product is, a database migration is the worst possible use of engineering time. Ship features, not infrastructure.

The strongest signal you should migrate: you've worked around MySQL three times in six months. JSON queries are slow. You're building tenant isolation in application code because RLS doesn't exist. You want pgvector for a new AI feature.

The strongest signal you shouldn't: nothing has actually broken. If your team has experience tuning MySQL and your app sits behind an ORM, the marginal benefit of switching is small.

For a deeper view on the trade-offs of moving infrastructure between providers, our analysis on the cost to migrate Firebase to Supabase covers the same dual-write and cutover patterns in a different stack. If your migration also involves changing hosting providers, the cost to migrate Heroku to AWS breakdown covers the parallel engineering effort.

How to reduce the cost without cutting corners

Five tactics that compress timelines without skipping validation:

• Use pgloader for the initial load. Don't write a custom dump-and-restore script. pgloader is faster, has been battle-tested for a decade, and handles 80% of type casts correctly out of the box.
• Migrate behind an ORM. If you're already on Prisma, Drizzle, or SQLAlchemy, the application work shrinks dramatically. If you're not, migrating to an ORM first (then to Postgres) is often cheaper than migrating raw SQL twice.
• Skip the live cutover if you can take a window. Most B2B SaaS can take a 2-hour Sunday-morning maintenance window. That choice alone removes 4+ weeks of CDC plumbing.
• Run the application against Postgres in CI for 2 weeks before cutover. Every test run against Postgres surfaces a GROUP BY issue or a LIMIT/OFFSET swap. Cheap insurance.
• Book an AI-native engineer who's done it before. Migrations are pattern matching. An engineer who's run pgloader against 4 production databases ships in 3 weeks; an engineer doing their first migration ships in 8. Every engineer on Cadence is AI-native by default (vetted on Cursor and Claude Code fluency before they unlock bookings), which compresses the schema-translation grunt work to a single day.

If you're considering a fresh stack altogether rather than migrating, our PlanetScale vs Neon comparison covers when each makes sense for new projects. And if your real complaint is query performance, you might fix that without a migration; see our piece on how to optimize Postgres queries or apply the same techniques to MySQL first.

The fastest path from MySQL to Postgres

Three steps:

1. Audit your application. Run grep for raw SQL strings. Count MySQL-specific functions. Estimate ORM coverage. This 1-day audit tells you whether you're a 2-week migration or a 12-week one.
2. Pick the cutover model. Maintenance window if you can take one (90% of teams can). Live cutover with Debezium or DMS only if you genuinely cannot tolerate downtime.
3. Book a senior engineer who's run this exact migration before. If you don't have one in-house, the fastest path is to book a senior engineer on Cadence for 4 to 8 weeks. Daily ratings, weekly billing, replace anyone after week one if they're not landing pgloader configs cleanly.

Most migrations stall on engineer availability, not technical complexity. A senior with no other context ships a 200GB migration in 3 to 4 weeks. Same migration takes 12 weeks as a side project.

If you're staring at a 6-month migration backlog with no spare senior engineer, book a senior on Cadence for the cutover work. 48-hour free trial, $1,500/week, replace any week. Most database migrations finish in under 8 weeks at the senior tier.

FAQ

How long does a MySQL to Postgres migration take?

Sub-100GB databases with ORM coverage take 2 to 4 engineer-weeks. 100GB to 1TB databases with mixed raw SQL take 6 to 12 weeks. Over 1TB with zero-downtime requirements takes 12+ weeks. The database size matters less than how coupled your application code is to MySQL-specific syntax.

Can I migrate without downtime?

Yes, with AWS DMS or Debezium handling change data capture and a dual-write strategy in your application. This adds 4 to 8 weeks to the project. If you can take a 2-hour maintenance window, skip the live cutover entirely; you save weeks of work and most of the risk.

What's the biggest risk in a MySQL to Postgres migration?

Silent data corruption from GROUP BY strictness differences, case-sensitivity flips, or ON UPDATE CURRENT_TIMESTAMP columns that no longer auto-update. None of these throw errors at cutover. They surface weeks later as missing data or stale timestamps. Run row-level checksums and a 24-hour shadow-read diff before declaring victory.

Should I use pgloader, AWS DMS, or Debezium?

pgloader for one-shot migrations under 500GB with a maintenance window. AWS DMS if both your source and target live in AWS RDS and you need continuous replication. Debezium if you need a permanent CDC pipeline (often as part of an event-streaming architecture you'll keep after migration). Most teams should start with pgloader.

Is the migration worth it if my MySQL stack works?

Probably not. Migrate when you have a concrete reason: you need JSONB query performance, row-level security for multi-tenant isolation, pgvector for AI features, or an extension MySQL doesn't have. Don't migrate because Postgres is fashionable; the engineering cost is real and the marginal benefit is small for a working stack.

Will my ORM handle the migration automatically?

Mostly. Prisma, Drizzle, SQLAlchemy, and Django ORM emit dialect-specific SQL and handle 90% of the translation. The remaining 10% is raw SQL strings in your codebase, custom database functions, and migration scripts written for MySQL syntax. Plan for at least a week of grep-and-fix work even with a clean ORM setup.