6.5k stars · PostgreSQL Licence · v3.6.9 (2022-10-24) · Track this in Scout
Loads data into PostgreSQL from other databases and from files, keeping going when individual rows fail.
▶Repo detailsthe review · specs · pros & cons · install
What it does
You write a short .load file saying where the data comes from and where it should go, then run one command. It loads through PostgreSQL's fast COPY path rather than row by row. Its central behaviour is transaction handling: PostgreSQL normally wraps a load in one transaction, so a single bad line throws away the whole table, and pgloader instead writes rejected rows to their own file and continues. It also reshapes values as it goes, and the README gives the clearest example of why that matters: MySQL allows a date of all zeros, which PostgreSQL will not accept, so pgloader turns it into an empty value. It reads SQLite, MySQL and SQL Server, and the repository also lists CSV, dBase and IBM IXF. Version 4 is a rewrite in Clojure and the project calls it a drop-in replacement for version 3, using the same .load syntax and the same flags. It is a loader, not a continuous link: it copies data once when you run it, and it does not keep two databases in step afterwards.
Why it matters
Who it suits. Anyone with records in one database who wants them in PostgreSQL, once. It suits a migration with messy data most of all, because the rejected-rows file turns an all-or-nothing failure into a short list of things to look at. It also suits repeated bulk loads from CSV, since a .load file is reusable and readable. Skip it if you need changes to flow continuously from one database to another, which is a different job and a different tool.
Verdict. Still the straightest route into PostgreSQL, and worth an afternoon on a copy of the data before you touch anything real. Be careful about which version you take. The newest tagged stable release is v3.6.9 from 24 October 2025, about twelve months old, while code was pushed on 14 September 2026, so the project is alive and the tag is simply behind. Version 4 is the active line, it needs Java 21 or newer, and the download is a pre-release build from the v4-clojure-rewrite branch. There is no version 4 Debian package yet, so apt-get install pgloader still gives you version 3. For an Oracle source this is the wrong tool and darold/ora2pg is the right one; Edition 48 covered it.
- One command and one short file turn another database into a PostgreSQL one.
- Bad rows go to a file instead of killing the whole load.
- The PostgreSQL Licence, which is about as permissive as licences get.
- Two live versions with different requirements, and the stable tag is a year old while the active work sits on a branch.
- Version 4 needs Java 21 or newer, which is a real install on a small machine.
- The package managers still ship version 3, so the documented v4 route means downloading a file by hand.
- dimitri/pgcopydb
By the same author, for PostgreSQL to PostgreSQL only; it copies a whole database in parallel and is faster for that one case, under the PostgreSQL Licence.
Track this in Scout 
darold/ora2pgOracle to PostgreSQL, GPL-3.0, and it also prints an estimate of how many person-days the migration would take; covered in Edition 48.
Track this in Scout
debezium/debeziumThe continuous version of this idea: Apache-2.0, it watches a database for changes and streams them out, rather than copying once.
Track this in Scout
# version 3, from the Debian or Ubuntu archive sudo apt-get install pgloader # version 4: download pgloader.jar from the v4-dev release, # then check it runs (needs Java 21 or newer) java -jar pgloader.jar --version # or use the container image docker pull ghcr.io/dimitri/pgloader:latest
