2026.10.01
PGHoard: PostgreSQL Backups and Recovery with Object Storage
PGHoard provides scheduled base backups, WAL archiving, point-in-time recovery, and standby initialization for teams managing their own PostgreSQL backup workflow.
What it does
PGHoard is a PostgreSQL backup daemon and restore tool. Its operating model combines a database base backup with subsequent write-ahead log (WAL) files, allowing a database to be restored to a selected point in time. Backups can be kept on a local filesystem or in object storage. The README specifically recommends object storage for a single-database host so recovery data can remain available if that host is incapacitated.
Known capabilities
PGHoard can create periodic base backups and receive WAL through pg_receivexlog, PostgreSQL’s archive_command, or the still-experimental walreceiver mode. It supports point-in-time recovery and can restore directly from object storage. It can also initialize a new standby from stored backups and configure it as a replicating hot standby.
The listed storage backends include AWS S3, Google Cloud, OpenStack Swift, Azure, and Ceph. Base backups and WAL can be compressed with Snappy, Zstandard, or LZMA, and backup data at rest can optionally be encrypted. The project also describes WAL prefetching during restore, retries for temporary object-storage connectivity problems, and WAL header verification. Archive sync and archive cleanup tools are available, along with on-disk statistics and alert files for monitoring integrations.
Who it suits
PGHoard is aimed at operations and platform teams already running PostgreSQL that want control over backup placement and recovery procedures. It may also suit organizations that need to use an existing object-storage account. This is not a database-independent backup button: operators need to understand WAL archiving, replication users, pg_hba.conf, wal_level, and max_wal_senders, while also defining retention, credential handling, and recovery testing practices.
Limits before adoption
The README says PGHoard can back up and restore PostgreSQL 9.3 and later, but is tested and actively developed with PostgreSQL 13 and later. It is implemented in Python and developed and tested with Python 3.10 and later. The README describes modern Linux x86-64 systems as the primary development and test environment; other platforms depend on the required modules. The 2.8.0 release notes add PostgreSQL 19 support, but the complete deployment environment should still be validated against the project documentation.
Object storage and encryption are not simply enabled by installing the daemon. Relevant Python dependencies may be optional, cloud credentials must be configured, and backup and restore permissions require separate design. Encryption adds key-management responsibilities; the supplied sources do not provide a complete key-rotation or disaster-recovery policy. Compression choices also affect speed, storage size, and restore load, so they should be tested with the target workload rather than selected solely from defaults.
Deployment considerations
Before deployment, verify that PostgreSQL permits WAL archiving and replication access, create an appropriate replication user, configure access rules for primary and standby nodes, and prepare the JSON configuration. The README recommends systemd on Linux; on systems without it, Supervisor or another process-control system may be used. Before production adoption, validate object-storage permissions, retry behavior after network interruptions, retention cleanup, WAL completeness for PITR, and recovery from an independent location if the PGHoard host is unavailable. GitHub metadata identifies Apache License 2.0 and an unarchived repository, but neither is a guarantee for a particular PostgreSQL version, cloud configuration, or recovery objective.
Sources
Sources checked: 2026-10-01