Funded upstream maintenance

The PostgreSQL Tools in Your Stack, Maintained on a Schedule

Priority handling for pgloader, pgcopydb, pg_auto_failover, and pgextwlist

These four tools are in production at Microsoft, VMware, Zalando, Aiven, PlanetScale, Neon, and Timescale. They are maintained by one person, and nobody's employer pays for that any more. If your migration, your upgrade path, or your failover depends on them, this is how you buy a place at the front of the queue — not hope, and not a consulting engagement.

9,400+GitHub stars across the four 2005pgloader maintained since 90k+databases migrated by pgcopydb inside Azure
See Pricing & Tiers See What's Shipping

Who Already Runs These in Production

pgcopydb powers Azure Database for PostgreSQL’s official Migration Service — 90,000+ databases moved in a couple of years.Microsoft, documented in the Azure migration guide

Cloud Postgres providers

Aiven, Neon, PlanetScale, Timescale (Tiger Data) and Zalando — which bundles pgextwlist in its Spilo image — ship these tools to their own customers.

Platform and infrastructure teams

VMware/Broadcom Tanzu Postgres documents pg_auto_failover as an officially supported HA option.

Consultancies and SaaS teams

pgloader has been the default answer for MySQL→PostgreSQL migrations since 2005, in agencies delivering client projects and in-house teams doing it once.

Unfunded Maintenance Becomes Your Problem

Not eventually — on the day you hit the bug

Most of these projects were born inside a company, on someone's salary. That sponsorship is gone; the software is still in production everywhere. The gap doesn't show up until the day your migration hits an edge case, or a failover doesn't complete, and the fix is upstream in a queue with no owner and no date.

The wait

A best-effort issue has no response time. Your release does. Whatever your team does while waiting is unplanned work.

The workaround

Patching around an upstream bug means you now maintain a fork, or a hack, forever — and you own every regression it causes.

The risk

A tool nobody is paid to maintain is a tool that can go unmaintained between your evaluation and your cutover.

The alternative quote

Consulting day rates to work around the problem locally cost more than a year of priority handling upstream, and fix it for nobody else.

Funded by the People Who Run It

One maintainer, twenty years, no competing agenda

These projects are authored and maintained by a single upstream developer — a PostgreSQL Major Contributor, working on this since 2005. Funding comes from the teams who depend on the tools rather than from an employer with its own roadmap, which is what keeps the priorities honest: no feature gating, no paid tier of the software itself, no strategy shift when someone gets acquired.

Direct funding

The people paying are the people running it in production. Their bugs are the roadmap.

Independent roadmap

Priorities come from real usage and production incidents, published in the open on the roadmap page.

Long-term continuity

Same maintainer across two decades and four projects. No handover risk, no rewrite-and-rename.

This is not theoretical. Redpill Linpro asked what the most efficient way to migrate a customer off Microsoft SQL Server would be, then sponsored MS SQL Server support in pgloader outright. It shipped, and it has been free for everyone since. The Sponsor and Per-Release tiers below are the same mechanism, open to anyone.

How Priority Handling Actually Works

Async, queue-driven, and boring on purpose — no calls, no consulting overhead

  1. 01

    You file it

    Issues and PRs go to the public GitHub repo, same as everyone else’s. Nothing moves to a private tracker.

  2. 02

    Your tier sorts it

    One prioritized queue across all four projects. Paid tiers move to the front of it.

  3. 03

    Triage on the clock

    Your tier defines the response and triage window, so you know when work starts — not just that it will.

  4. 04

    It ships in a release

    Fixes are grouped into quarterly releases. Per-release sponsors can fund and shape a specific cycle.

  5. 05

    Everyone gets it

    The fix lands upstream, open source, in the next public release. You stop maintaining a workaround.

Four PostgreSQL Tools, One Maintainer

Migration, replication, high availability, and multi-tenant extension safety

pgloader

MySQL, SQLite and MS SQL Server → PostgreSQL migration

Connects to the source database, converts the schema to PostgreSQL conventions, and loads the data in parallel from one command. Maintained since 2005, and the tool named in nearly every MySQL-to-PostgreSQL migration guide written since.

6,471 GitHub stars · Oracle support: open for funding

pgloader maintenance →

pgcopydb

PostgreSQL-to-PostgreSQL copies and major-version upgrades

Copies a database with minimal downtime using logical replication — the practical path for a major-version upgrade or a move between providers. Powers Azure Database for PostgreSQL’s official Migration Service.

1,531 GitHub stars · Microsoft, PlanetScale, Neon, Timescale

pgcopydb maintenance →

pg_auto_failover

Automated PostgreSQL high availability and failover

One monitor, N Postgres nodes, automated promotion on failure — no external consensus cluster to run and babysit. Built on PostgreSQL’s own replication, so it stays predictable and testable.

1,362 GitHub stars · VMware/Broadcom Tanzu Postgres

pg_auto_failover maintenance →

pgextwlist

Safe extension installs for non-superuser tenants

Lets a cloud provider offer CREATE EXTENSION to customers who are not superusers, through a whitelist and a controlled privilege-elevation model. Small, and load-bearing wherever it runs.

102 GitHub stars · Aiven, Zalando, Microsoft Azure

pgextwlist maintenance →

Pricing & Tiers

Pick the level of priority your production actually requires

One subscription covers every project here — pgloader, pgcopydb, pg_auto_failover, and pgextwlist. Tiers differ by how fast your issues move and how much say you get, not by which tools you're allowed to use.

Community

€0

For evaluating, or non-critical use.

Best-effort, through GitHub, like everyone else.

Supporter

€100/mo

Your issues stop getting lost in the queue.

Priority queue, answered within a few days.

Get this tier →

Recommended

Professional

€800/mo

When a production system depends on the tool.

Patches triaged under an SLA, land in the next release.

Get this tier →

Sponsor

€2,000/mo

When your roadmap depends on its roadmap.

Roadmap input, and development bandwidth reserved for you.

Get this tier →

Per-Release Sponsor

€10,000/release

Time-critical dependencies, one release at a time.

Prioritized PRs and features, credited in the release notes. One sponsor per release.

Get this tier →

Fast-Lane

€3,000/issue

One urgent blocker, handled outright.

Guaranteed resolution in the next release, no subscription required.

Get this tier →

Every tier is a support contract, not a donation: the code stays open source and free to use at €0, and what you're buying is a place in the queue. Annual invoicing and purchase orders are available — start at the checkout and say so.

Why This Pays for Itself

The line item you compare it against is engineering time, not software

When a migration stalls or a failover setup misbehaves, your team either waits or builds something risky. Priority handling converts that open-ended wait into a defined timeline and a fix that lands upstream, where it stops being yours to carry.

Blockers resolve on a date

A migration cutover you can schedule is worth more than one that’s ready “when upstream gets to it”.

Fewer incidents in the risky window

Migrations and HA changes are exactly when an unfixed edge case turns into an outage.

No fork to maintain

An upstream fix is maintained by upstream. A local patch is maintained by you, in every release, forever.

This isn’t support as a cost centre. It’s upstream reliability as a delivery advantage.

Stop Waiting on Upstream

Pick a tier, get a place in the queue, keep the software open source

See Pricing & Tiers Read the Roadmap First

Get More Out of the PostgreSQL You Already Run

One learning path, four ways in — from The Art of PostgreSQL

Funded maintenance keeps the tools working. How much you get out of PostgreSQL itself is a different problem — query design, data modelling, and knowing which of its features you are not using. That is what the rest of The Art of PostgreSQL is for.

These aren’t four separate products. They’re one path: start with the book for the foundations, take the course to structure and deepen them, join a masterclass when you want to go further on a specific topic with the author in the room — and license it for the team when it should be everyone’s baseline, not one person’s.

Book

Read it yourself. SQL and data modelling from the ground up — the foundation the rest builds on.

Course

Work through it. Structured modules and hands-on exercises against real datasets, at your own pace.

Masterclass

Ask questions live. Three-hour sessions with the author on one topic, or the full curriculum.

Team

Bring the whole team. Per-seat licensing from five people up, with a dashboard to manage progress.

Copyright 2026 © Dimitri Fontaine. All rights reserved.