Pigsty: a self-hosted PostgreSQL distribution with 575 extensions and 12 kernel forks

The gap Pigsty fills between a bare Postgres install and a managed service

Installing PostgreSQL is easy. Running it as a service with failover, backups, connection pooling, TLS, access control and dashboards is a multi-week project that most teams rebuild from scratch. Pigsty targets exactly that gap. The README describes it as an "Enterprise-Grade Open-Source PostgreSQL Distribution with HA, PITR, IaC, Monitor, and 575 PG extensions", and the project positions itself against managed RDS offerings on cost while keeping the operational surface on hardware you control.

The audience is specific: infrastructure and database engineers who already have Linux hosts, SSH access and sudo, and who are willing to describe their cluster in a configuration file rather than click through a console. The README states the system runs on bare Linux "without Docker & K8S", which is a deliberate constraint rather than a missing feature. Kubernetes users are not the target here, and the project links to an essay arguing that position.

The scope goes past PostgreSQL. The README lists bonus modules for Redis and Valkey, MinIO, Etcd, Docker, DuckDB and Supabase, so the same inventory can bring up supporting infrastructure alongside the database. That breadth is the reason the repository has roughly forty top-level playbooks, one per component or lifecycle action.

How Pigsty works: Ansible playbooks, a local repo, and a declarative inventory

Pigsty is a Shell and Ansible codebase. The top-level layout shows the shape of it: pgsql.yml, node.yml, infra.yml, redis.yml, minio.yml, etcd.yml, kafka.yml, docker.yml and mysql.yml each bring up a component, and matching -rm.yml playbooks tear them down. There are also narrower playbooks for lifecycle operations such as pgsql-pitr.yml, pgsql-migration.yml, pgsql-user.yml, pgsql-db.yml and pgsql-monitor.yml. Configuration lives in pigsty.yml, with additional cache.yml, cert.yml and slim.yml entries.

The Makefile confirms the packaging model. It defines separate tarballs per platform: pigsty-pkg-v4.5.0.el8, el9, el10, d12, d13, u22, u24 and u26, each with an architecture suffix resolved from uname -m, mapping arm64 to aarch64. That is the mechanism behind the "16 Linux Platforms" claim: Pigsty ships a local package repository per OS, so nodes install from a mirror the control node serves rather than from public mirrors. The bootstrap step in the Makefile tip block is what prepares that local repo and Ansible itself.

The data flow is conventional Ansible. A control node holds the inventory and the local repo, connects to managed nodes over SSH, and applies roles from the roles/ directory. HA is assembled from a preconfigured stack rather than hand-written scripts, and the README points to haproxy, pgbouncer and VIP for service access and routing. Monitoring is a Victoria and Grafana stack with dashboards for PostgreSQL, infrastructure and nodes, and a public demo is linked for inspection before you install anything.

Installing Pigsty and bringing up a first PostgreSQL cluster

The README gives a single bootstrap command for the latest release. It downloads and runs the installer script, which prepares the environment on the node.

curl -fsSL https://repo.pigsty.io/get | bash -s v4.5.0

After that, the Makefile tip block shows the intended sequence: prepare the local repo and Ansible, then run the pre-check and configuration step.

./bootstrap     # prepare local repo & ansible
./configure     # pre-check and tem

The comment on the configure line is truncated in the Makefile as shown, so treat the step as a pre-check and configuration pass rather than assuming what it writes. The tip block also states the prerequisite plainly: run on a Linux node with passwordless sudo and SSH access. The Makefile's default target prints the detected architecture and those same commands, so running make on a fresh node is a way to see what the tooling expects before committing.

With the repo and Ansible in place, the cluster itself comes from the inventory in pigsty.yml applied through pgsql.yml. The repository does not document a rollback path for a partially applied cluster in the files available here; the -rm.yml playbooks are the removal mechanism, and they are separate from the install playbooks. Plan the inventory before the first run, because the playbooks converge a described state rather than offering an undo.

Where Pigsty is the wrong tool

The clearest boundary is the host. Pigsty manages Linux nodes, and the packaging targets specific distributions and versions. If your database runs on a managed platform where you cannot install packages, configure sudo, or run Ansible against the host, Pigsty has nothing to attach to. The README's own framing, "Run on bare Linux without Docker & K8S", means container-only environments are outside the design.

The second boundary is operational appetite. Adopting Pigsty means adopting its inventory format, its playbook names, its local repo and its monitoring stack together. A team that wants only PostgreSQL with streaming replication and nothing else will carry a large amount of surface area it never uses. The README lists 575 extensions and 12 kernel forks as a feature; for a small deployment that is inventory to reason about, not a benefit.

The third is failure recovery. The repository exposes pgsql-pitr.yml for point-in-time recovery and separate removal playbooks, but the project does not describe a general rollback for a failed convergence. Ansible playbooks are not transactional. If a run fails midway, the state on the node is whatever the completed tasks produced, and the operator has to reason about it from the task output.

Pigsty compared with running PostgreSQL from a container image

The obvious alternative is the official PostgreSQL container image plus a Compose or Kubernetes manifest. The difference is where the configuration lives. A container setup describes a process and its environment variables; the host is abstracted away, and persistence, backups, TLS and monitoring are separate concerns you wire up yourself. Pigsty describes a machine: packages installed from a local repo, a filesystem layout, certificates, users, access rules, and monitoring agents, all applied by Ansible to a node you own.

That difference decides the fit. Containers make the database portable and the surrounding operations your problem. Pigsty makes the surrounding operations part of the product and the node non-portable in the sense that it is configured rather than scheduled. A container image also cannot easily give you a choice among 12 kernel forks; Pigsty's kernel documentation lists variants including Citus, Babelfish, IvorySQL, OpenHalo, Percona TDE, OrioleDB, AgensGraph, PGEDGE, PolarDB PG and Cloudberry, each packaged for in-place replacement. That list is the strongest argument for Pigsty over a generic image, and it is also the reason the project cannot be a thin wrapper.

Maintenance, upgrades and what the Apache-2.0 licence means here

Pigsty is not archived, and the last push to the main branch was on 2026-09-21. Release cadence is visible in the notes: v4.3.0 added 510 extensions, v4.4.0 focused on the CLI, and v4.5.0 arrived on 2026-08-14 with Silo, Valkey and Kafka in the title. That is roughly a quarterly rhythm across the three most recent releases, with patch activity between them.

Upgrade cost is tied to the packaging model. Because the repository ships per-platform tarballs and a local repo, moving to a new version means fetching a new package set and re-running the playbooks against the inventory. The Makefile carries a VERSION variable defaulting to v4.5.0, and the bootstrap command takes the version as an argument, so pinning is explicit rather than implicit. The release notes page is the place to check what changed between the version you run and the one you intend to move to.

The licence is Apache-2.0, stated in the README badge, the Makefile header and the repository's LICENSE file, with a NOTICE file alongside it. That permits commercial use and modification, and the NOTICE file exists to carry attribution. Pigsty also sells support and there is a price page linked from the README, so there is a commercial offering around an open core. Whether that matters depends on your organisation's policies; this is a description of the licence and the commercial links, not legal advice.

Editorial conclusion

Pigsty fits teams that run their own Linux hosts, want HA and PITR configured from a declarative inventory, and need access to extension or kernel variants that managed services do not offer. It does not fit anyone who wants a single container, a managed endpoint, or a platform that ignores the host operating system. Before adopting it, confirm that your nodes match the 16 Linux platforms listed in the platform reference, check the kernel and extension lists for the specific build you need, and read the release notes for v4.5.0 to see what changed since the version you plan to start from.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. pgsty/pigsty on GitHub
3. Project website
4. README
5. Releases