A concept, not a checklist
pgloader is meant to let you implement Continuous Migration when moving to PostgreSQL — a project methodology built to reduce the risk inherent to a complex migration, described in full in the Migrating to PostgreSQL course, whose first four modules are free.
CI/CD, applied to the migration itself
Continuous Migration is comparable to continuous integration and continuous deployment — CI/CD, applied to the migration rather than to application code. Set up a target PostgreSQL environment first, then use it every day as developers work on porting the software to it. As soon as that environment exists, fork a CI/CD setup onto the PostgreSQL branch of the code repository. In parallel, the data keeps getting migrated over and over — not once, but continuously — so the target is never stale by more than a day.
Risk spent gradually, not all at once on D-Day
The alternative is the big-bang migration: freeze, migrate everything in one pass, cut over, hope. Continuous Migration exists because that alternative concentrates all of a project's risk into a single event, at the exact moment the least is known about what will actually go wrong. Splitting the work into chunks surfaces problems early — while they're still cheap to fix — and builds a track record instead of a guess: by the time D-Day is scheduled, the migration has already run successfully, many times, against real current production data.
TCO is the reason people start the conversation, rarely the reason to finish it
Licensing cost is usually what puts PostgreSQL on the table — no per-core or per-user fee, on the RDBMS itself or on its advanced features. But treat that as the whole case and the project reads as pure cost-cutting, which makes it the first thing cut when budgets tighten. The costs that hold up under scrutiny:
No per-instance licensing means standing up as many replicas, or a full container-based test environment, as the project needs to actually understand the trade-offs — not just what the budget for extra licenses allows.
Point-in-time recovery, logical replication, table partitioning, JSONB and full-text search, and server-side procedures in more than one language — in the base package, not gated behind an enterprise SKU.
CTEs, window functions, grouping sets, and hypothetical-set aggregates by default — plus room to add your own aggregate and window functions when the standard doesn't cover a case.
Four line items — and the one people underestimate is usually the biggest
Moving relations and attribute domains sounds trivial between two RDBMS — until different systems disagree on what those domains mean under the same name. Automatable, and where pgloader spends most of its effort.
Usually the most expensive line item. Every automated test needs to pass against PostgreSQL, and even with an ORM doing most of the translation, some SQL rewriting is normally unavoidable.
The cutover itself — new architecture, new code deployed to it, a maintenance window or a read-only switch, the data moved, the pre-opening checks, then production back on for everyone.
Hard to put a dollar figure on, easy to underweight: whatever the team assigned to this migration isn't shipping elsewhere for its duration.
The distinction that decides how much of your architecture is actually up for reconsideration
A port makes an existing system also run on PostgreSQL, alongside whatever it already ran on — the goal is a minimal set of changes, because the software still has to work everywhere else it already runs. A migration commits to a single RDBMS going forward, which means the architecture is free to change wherever that simplifies the result — but usually only as far as it simplifies migrating and maintaining the new system, not as a ground-up redesign. Get this distinction wrong at the start and either the project scopes in far more rework than it needs, or it scopes out changes that would have made the whole thing easier.
This page is the idea — not the step-by-step
pgloader is the tool that makes the third step of this method possible: fully automated database migrations, run as a nightly job for the whole duration of a migration project. For the full, hands-on step-by-step — target architecture, casting rules, the D-Day cutover checklist, and a course that walks through it with a real dataset — see the Methodology and the course on mysqltopgsql.com.
Copyright 2017-2026 © Dimitri Fontaine. All rights reserved.
Postgres, PostgreSQL and the Slonik Logo are trademarks or registered trademarks of the PostgreSQL Community Association of Canada. pgloader is an independent, unaffiliated project.