Current Work and Priorities

Driven by real-world usage and production issues

This roadmap reflects the actual backlog across pgloader, pgcopydb, pg_auto_failover, and pgextwlist. Work is prioritized based on production impact and user support. Most items come from real-world usage — GitHub issues, production incidents, and comparison against the rest of the PostgreSQL tooling ecosystem.

Most of these projects were born inside companies — an employee's or a contractor's job — with clear sponsorship behind the work. That sponsorship is gone today, even though the software is still maintained, still open source, and still relied on in production everywhere.

Project by Project

Last release, recent improvements, and what's next

pg_auto_failover

1,362 stars v2.2 · Apr 3, 2025 Unreleased work · Jul 2026

Known users: Microsoft (Citus Data, its origin) and VMware/Broadcom Tanzu Postgres (an officially documented HA option)

v2.2 added PostgreSQL 17 support and Citus v13 compatibility. Since then, a large PG17/18/19 and node-lifecycle body of work has merged to main, not yet tagged into a release.

Recent improvements

PostgreSQL 17/18/19 compatibility work merged to main
New declarative pg_autoctl node lifecycle command for container/K8s deployments
guard_data_loss GUC and --allow-data-loss escape hatch for stuck multi-standby failovers
Fixed a buffer overflow in timeline-history parsing on long-lived clusters
Removed ~4,500 lines of unmaintained Azure integration code
New pgaftest test framework and a CI overhaul

Big features on the roadmap

Multiple monitor nodes via RAFT

The most persistent open request since the project began

  • Removes the monitor as a single point of failure
  • RAFT-style consensus across monitor nodes, rather than a single authority

Connection pooling as a managed node type

A new node kind with failover-aware reconfiguration

  • Fixes the Citus pg_dist_poolinfo gap left stale after a failover
  • Answers repeated requests for HAProxy/pooler integration

Disaster recovery, with archiving built in

HA + DR as one tool — backups stay someone else's job

  • Restore a cluster from periodic base backups plus continuous WAL archiving (local cache & cloud), not only from a live standby
  • Bootstrap a whole new geo-location straight from archives, with point-in-time recovery (PITR) available across the entire cluster, not just a single node

Cascading replication for multi-DC

Round-trip optimized, self-healing topologies

  • Multi-datacenter deployments with round-trip-optimized replication paths
  • Local leader maintenance if a node fails, with dynamic, automatic topology adjustments driven by a declarative setup

Logical replication nodes

Mixed workloads alongside physical standbys

  • First-class logical replication nodes for mixed use-cases — CDC consumers and analytics replicas alongside physical standbys
  • Native support for wal_level=logical, integrated into the automated failover state machine

Cluster upgrades

Two supported paths to a new major version

  • Rolling upgrades orchestrated around pg_upgrade, node by node
  • Online, near-zero-downtime upgrades driven by logical replication

pgloader

6,471 stars v3.6.9 · stable, Oct 2022 v4 preview · Jun 2026

pgloader is mid-rewrite: v3 (Common Lisp/SBCL) remains the stable, production release, while v4 — a from-scratch rewrite in Clojure on the JVM, distributed as a single self-contained JAR — is under active development as a drop-in replacement for v3's .load file syntax and CLI. The main benefit of running on the JVM: pgloader can now talk to any source database through its standard JDBC driver, already usable today, instead of needing a hand-rolled connector per source.

Recent improvements

MySQL binary/UUID/inet transforms, and MSSQL Azure AD authentication (MSAL4J)
MSSQL SEQUENCE migration and multi-column foreign key fixes
PostgreSQL 63-character identifier collision detection (closes a decade-old issue)
MySQL .my.cnf credential lookup support
A sweep of longstanding CSV/fixed-width loading bugs, plus a new date-format option
SQLite MATERIALIZE VIEWS support and multi-arch v4 Docker images
408 issues closed and 55 PRs merged in the past two months alone, driven by the v4 rewrite push

Big features on the roadmap

Oracle as a source database

The most-requested source, still missing

  • The single most-discussed open request on the tracker
  • Full Oracle-to-PostgreSQL migration on par with existing MySQL/MSSQL support

ON CONFLICT DO NOTHING support

Upsert-style loading instead of hard failures

  • Highest-reaction open issue on the tracker
  • Avoid aborting a load on duplicate keys during incremental re-runs

Emit a .sql file instead of applying it

A dry-run / review mode

  • Let teams review or hand-apply a migration before it runs
  • Useful for change management and compliance sign-off

pgcopydb

1,531 stars v0.18 · Jun 27, 2026

Known users: PlanetScale, Neon, Timescale (Tiger Data), Meltwater, and Microsoft — pgcopydb powers Azure Database for PostgreSQL's official, self-serve Migration Service, the main driver behind its Single Server to Flexible Server migration (90k+ databases in a couple of years)

v0.18 shipped PostgreSQL 17/18 support, made pgoutput the default CDC plugin, rewrote change-data-capture storage onto SQLite for crash-safe resumption, and added --all-databases and Citus-to-Citus migration support.

Recent improvements

CDC storage rewritten onto SQLite catalogs for crash-safe resumption
--all-databases to clone an entire instance in one command
Citus-to-Citus migration support for distributed clusters
Regex-based filter syntax, and TimescaleDB extension support
AlloyDB compatibility fixes, and a client_encoding/SQL_ASCII COPY fix
LOCK TABLE failures now recover via SAVEPOINT instead of aborting the worker

Big features on the roadmap

Publication/subscription follow mode

The model AWS DMS, Google Cloud DMS, and pglogical build on

  • Lets tables be added mid-migration without a fresh snapshot
  • Aligns pgcopydb's CDC engine with the pub/sub model used across the ecosystem

Automatic DDL/schema-drift sync

Keep up with the source during --follow

  • Propagate new tables/schemas created on the source after initial sync
  • The most-cited gap versus native logical replication workflows

Finer-grained filtering

Roles, foreign keys, and casts

  • Extends the regex filter system shipped in v0.18 to more object types
  • Avoids clobbering operational roles and custom casts already on the target

Built-in cutover orchestration

A turnkey pgcopydb switchover

  • Check replication lag and confirm safe-to-flip automatically
  • The last-mile step tools like pg_easy_replicate already offer

pgextwlist

102 stars v1.20 · Jul 8, 2026

Known users: Aiven, Zalando (bundled in its Spilo Postgres image), and Microsoft Azure Database for PostgreSQL

v1.20 fixed a SQL-injection vector in extension schema/owner substitution (CVE-2023-39417) and added extwlist.restrict_to_database_owner for finer-grained control over who can install whitelisted extensions.

Recent improvements

PostgreSQL 18 compatibility, with PG 19/20 already in the CI test matrix
Extension drop-hook and COMMENT ON EXTENSION support
Transaction-validity checking before superuser operations
Packaging repository moved to Debian Salsa

Big features on the roadmap

On-demand extension installation

Reviving the pginstall model

  • Fetch and install whitelisted extensions from a build-farm-backed registry at CREATE EXTENSION time, instead of requiring them pre-installed on disk
  • Modernizes pginstall, Dimitri's earlier, more ambitious follow-on to pgextwlist — dormant since 2016 but cited as prior art in PGXN v2's current binary-packaging redesign

Private, mirrored extension repositories

For cloud providers and enterprises

  • Whitelist internal, non-public extensions alongside upstream ones
  • Drawn directly from pginstall's own design docs for mirroring and merging upstream repositories

Finer-grained per-role/per-database controls

Building on v1.20's ownership check

  • Extends extwlist.restrict_to_database_owner with more granular role- and database-scoped policies

What this means

This is not a speculative roadmap. It is a reflection of actual production needs across teams using these tools today. Supporting the projects directly influences what gets fixed, improved, and released next.

How work is prioritized

  • Production blockers and data-loss risks come first
  • Paid support tiers move issues forward in the queue
  • Work is grouped and shipped in quarterly releases
  • Cross-project improvements are prioritized when they unlock multiple use cases

Influence the roadmap

Fund the work that matters to you