Pigsty v4.4 is officially out. On the surface, this is a routine maintenance release: PostgreSQL 18.4, 531 extensions, a PostgreSQL 19 beta, and 14 validated offline installation artifacts. The changes really worth discussing, however, are concentrated in the software repository and command-line tooling.
Pig 1.5 completes a redesign of the command line for day-to-day PostgreSQL operations. Cloning a database, forking an instance, performing point-in-time recovery—actions once scattered across Ansible, shell scripts, Patroni, and pgBackRest—now share one consistent CLI.
At the same time, we reorganized the PostgreSQL kernel forks in the repository: adding Babelfish PG 18, filling out pgEdge PG 15–18, AgensGraph PG 17, and OrioleDB PG 16–18, and providing our own packages for PolarDB and IvorySQL.
This release also updates the self-hosted Supabase template to the latest upstream versions and resolves a batch of compatibility issues. It adds one-click deployment templates for Immich, a self-hosted photo library; JumpServer, a bastion host; and Maybe, a personal finance manager.
Pig 1.5: One Interface for Operations#
pig began as a PostgreSQL extension package manager, then gradually took on Pigsty installation, software repository, and PostgreSQL management duties. By version 1.5, it is no longer merely a tool that “can run lots of commands.” It is becoming a coherent interface for operating PostgreSQL.
| Command | Boundary | Typical Uses |
|---|---|---|
pig pg | Local PostgreSQL primitives | Start/stop, status, connect, maintenance, database cloning, local PGDATA forks |
pig pt | Patroni cluster operations | Restart, rebuild replicas, switchover, failover, configuration, and logs |
pig pb | Low-level pgBackRest primitives | Backups, repositories, backup sets, cleanup, and low-level restore |
pig pitr | Recovery orchestration | Coordinate Patroni, PostgreSQL, and pgBackRest to perform PITR |
The most important change in this round is not the number of commands, but the separation of responsibilities. In the past, these operations depended largely on DBAs remembering SOPs and command aliases: which tool to call, what to do next, and what side effects to expect. That operational knowledge is now encoded directly in the commands, with high-risk operations consistently proceeding through the same chain:
state → plan → precheck → execute → verify → result → next_actions
Results and help at every stage can be emitted as human-readable text or as JSON/YAML for machines and agents. Through this Agent-Native interface, DBAs, scripts, and agents can all use the same entry point and receive the context, risk assessment, and suggested next steps they need.
Enough abstraction. Let’s look at a few concrete examples.
Clone: Branch a Single Database#
The new pig pg clone command can clone a single database quickly.
pig pg clone meta meta_dev --plan # Preview the plan
pig pg clone meta meta_dev -y # Create the database copyThere is an often-overlooked boundary here: CREATE DATABASE ... TEMPLATE terminates existing sessions on the source database. In other words, database cloning is fast, but it is not impact-free. The point of --plan is to lay out those side effects before you take action.
These cheap branches are extremely useful for development and testing, data analysis, model experiments, and counterfactual reasoning by agents. Production stays untouched while experiments run against the copy. If you break it, delete it and create another branch. For details, see Instantly Clone a PostgreSQL Database—No Black Magic Required.
Fork: Sandbox an Entire Instance#
Database cloning creates a copy of one database. pig pg fork works at the level of an entire PostgreSQL instance: a physical, PGDATA-level fork.
pig pg fork init dev --start # Fork to /pg/data-dev and start it
pig pg fork list # List local forked instances
pig pg fork stop dev # Stop a forked instancePig writes metadata for managed forks and provides list, start, stop, and rm lifecycle commands. On CoW-capable XFS, a new fork initially consumes virtually no additional space; only newly written or modified blocks use capacity afterward. Pig also assigns a free port automatically, allowing the forked instance to run alongside the original.
This is especially useful in two situations: preserving a low-cost local branch before a large-scale operation that is difficult to roll back, and starting an out-of-band instance during incident recovery to verify a PITR target and inspect data quickly.
Go Back in Time: Recovery Starts with a Plan#
The most dangerous part of database recovery has never been the absence of one command. It is the number of steps, the blurry boundaries, and the ease of making mistakes under incident pressure.
Pig 1.5 draws a clear line between low-level recovery and high-level orchestration:
pig pb restoreis the low-level pgBackRest recovery primitive, responsible only for files and the recovery target.pig pitris the recovery orchestrator for Pigsty/Patroni environments, coordinating Patroni, PostgreSQL, and pgBackRest.
pig pitr -t "2026-07-10 12:00:00+08" --plan
pig pitr -t "2026-07-10 12:00:00+08" -yRecovery commands must now specify an explicit target: the latest state, a backup consistency point, a timestamp, an LSN, a transaction ID, or a named restore point. Omitting the target can no longer be interpreted as some dangerous default. Structured output no longer counts as confirmation either; automation that performs destructive operations must explicitly pass -y/--yes.
For managed data directories, pig pitr checks the environment, stops Patroni and PostgreSQL, runs the pgBackRest restore, starts PostgreSQL according to policy, verifies the recovered state, and finally reports follow-up actions. A human operator or higher-level automation then validates the data, returns the instance to Patroni control, and switches traffic.
The point is not “one-click recovery.” It is to codify the SOP most likely to go wrong during an incident: review the plan, execute it, then verify the result.
PostgreSQL 18.4, 19 Beta, and 531 Extensions#
The operational interface is the through line of this release, but the distribution’s foundation has not stood still.
Pigsty v4.4 makes PostgreSQL 18.4 the production default and adds a minimal PostgreSQL 19 beta template for evaluation. PG 19 beta1 is not production-ready, and pgBackRest 2.58 as shipped with v4.4 cannot recognize its control-file format, so this template is strictly for experimentation and evaluation.
Pigsty’s PostgreSQL extension catalog grows from 510 in v4.3 to 531. By category, pg_ducklake brings DuckDB, Parquet, and lakehouse capabilities into PostgreSQL; pg_stat_plans and pg_stat_backtrace improve observability for query plans and process call stacks; and the upgraded pgmnemo and newly added psql_bm25s target agent memory and BM25 full-text search, respectively.
Meanwhile, OrioleDB expands to PG 16–18 and now defaults to PG 18; pgEdge covers PG 15–18; Babelfish covers PG 17–18; IvorySQL enters the 5.x line; AgensGraph moves to PG 17; and Cloudberry and PolarDB both receive reorganized paths and packages.
These details may look miscellaneous, but this is the work of a distribution: keeping the PostgreSQL mainline, extension ecosystem, and kernel forks simultaneously usable, installable, and upgradeable.
Application Updates: Immich, JumpServer, Maybe, and Supabase#
This release adds templates for Immich, JumpServer, and Maybe, and updates Supabase.
Immich: Put Your Photo Library on Real PostgreSQL#
Immich is an open-source, self-hosted photo and video management service—think Google Photos or iCloud Photos in your own home. It provides automatic mobile backup, albums, maps, face recognition, and semantic search. Its backend uses PostgreSQL, vector search, caching, and machine-learning services. Smart search and face recognition require VectorChord’s vchord extension, which Pigsty provides directly.
Immich still stores original photos in a filesystem directory and does not support object storage directly. If you want to separate the storage pool, JuiceFS can mount MinIO or S3 as a local filesystem.
JumpServer: Bring the Bastion Host into the Stack#
Bastion hosts are a hard requirement for many enterprises, and JumpServer is one of the common open-source choices. JumpServer 4.x stores its core metadata in PostgreSQL, so Pigsty now provides a matching deployment template.
Maybe also joins the application catalog in this release. It is a personal finance and asset management tool. The three templates serve different purposes, but they share the same principle: applications can run in containers without letting their data drift along with the containers.
Supabase: Updating Means More Than Swapping Images#
Supabase moves quickly. It also has the most components—and the most opportunities for compatibility problems—of any Pigsty application template. v4.4 brings Studio, Auth, PostgREST, Realtime, Storage, Analytics, Edge Runtime, and the rest of the stack up to their July 2026 upstream versions, along with a coordinated round of adjustments.
Analytics now lives in a dedicated _supabase database and _analytics schema, keeping log-analysis tables separate from application objects. We added a pg_stat_statements compatibility view for Studio so its query-performance page works correctly. We also adapted the stack for the new Publishable Key and Secret Key, and adjusted Kong routes, sensitive Realtime endpoints, S3-compatible APIs, and service health checks.
With an application like Supabase, getting one container to start means nothing. The job is done only when more than a dozen components can be upgraded together and still work together. v4.4 fixes exactly these unglamorous issues that determine whether the template is actually usable.
No More Manually Entering the VIP Interface#
Another change I particularly like is automatic VIP interface detection.
Previously, vip_interface and pg_vip_interface defaulted to eth0. Enabling a NODE/PG VIP required users to configure the interface name manually, which was tedious.
v4.4 adds automatic detection and changes the defaults to auto: Pigsty takes each node IP from the inventory, resolves the actual network interface that owns it, and passes that result to Keepalived or VIP Manager. Explicit configuration is still supported, but most users no longer need to log in, run ip addr, and come back to fill in a parameter. This feature is only a few lines of configuration, yet it directly prevents an entire class of deployment failures. The experience of a distribution is often defined by small details like this.
Backups Now Default to Zstandard#
pgBackRest previously used LZ4 compression by default. LZ4 is fast and offers high throughput, and it remains a good fit for wal_compression. Backup repositories, however, care more about compression ratio, so v4.4 changes pgBackRest’s default algorithm to Zstandard. In testing, a small increase in decompression overhead improved the compression ratio from 2.x to 3.x and saved roughly another third of the backup space. That is an excellent trade.
The switch also exposed a problem: the official IvorySQL kernel was not built with options such as --with-lz4 and --with-zstd, so it could use neither LZ4 nor Zstandard. That led directly to the next change: standardizing how PostgreSQL kernel forks are built.
Standardizing PostgreSQL Kernel Fork Builds#
Pigsty supports many flavors of the PostgreSQL kernel. PolarDB and IvorySQL previously used packages built upstream. IvorySQL’s official build omitted several important compile-time options, while PolarDB had no Ubuntu 26.04 packages. I reported both issues upstream. Ubuntu 26.04 build support has now been merged in PolarDB #650, and IvorySQL #1377 confirms that the missing options will be added in the next release. The upstream binary packages, however, will take another release cycle.
I was not going to wait that long. Since I already build so many kernel forks myself, two more will not hurt—and this is a good opportunity to standardize the FHS layout once and for all. Take PolarDB: the upstream package is named polardb-for-postgresql and installs to /u01/polardb_pg_17; Pigsty’s package is named polardb-17 and installs to /usr/polar-17. The default port, runtime search paths, development headers, and extension build tooling are standardized along with it.
To make PolarDB builds reproducible, we also split its PFSD development library into a separate polarstore package. The open-source edition also removes the PolarDB Oracle-compatibility kernel and its dedicated monitoring configuration; this closed-source compatibility path is no longer listed as built-in support.
This work also prepares for the next step. Pigsty’s 500-plus extensions currently target mainly vanilla PostgreSQL. Next, I want to extend the build matrix—“5 vanilla PG major versions × 16 Linux platforms, including online-only EL8 on both architectures”—to more than a dozen PostgreSQL kernel forks, giving them access to the complete PostgreSQL extension ecosystem instead of leaving each one to bundle a handful of extensions piecemeal in RPMs or Docker images. That is what a Meta Distribution should look like.
Closing Notes and What’s Next#
Most of the work involved in building a distribution does not make for a pretty demo: rename packages, straighten out directories, add dependencies, fix build scripts, then run all 14 deployment tests. But if nobody does that work, “out of the box” is just advertising copy.
Bring upstream diversity under one set of engineering conventions, and leave the last-mile headaches to the distribution. That is Pigsty v4.4.
With Pigsty 4.4 complete, we have already begun preparing version 5.0. There may be a transitional 4.5 release before 5.0.
Version 5.0 will ship alongside full support for PG 19 this September. PG 19 introduces many powerful features, and Pigsty 5.0 will make targeted adjustments to take full advantage of them. Some of the groundwork is already done. For example, this release updates pg_exporter to 1.3.0, adding support for new PG 19 monitoring metrics; Patroni parameter templates have also reserved the necessary positions and placeholder values for PG 19 changes.
Pigsty 5.0 will have a dedicated enterprise software artifact repository with a different policy from the open-source edition: more conservative updates, retention of every historical package version, debug packages and hotfix packages, plus regular snapshots. To make that possible, we built a repository management tool that unifies repository operations across APT and DNF. We call it sow—a female pig—a natural counterpart to Pig, the package manager and resident piglet.
We are also trying a few interesting things. One is rewriting Patroni in Go; for the first phase, at least, we have rewritten Patroni’s client tool to provide a better management experience. We call this project Boar—as in a male pig. Together with sow and Pig, it completes the family, right at home in Pigsty.
v4.4.0 Release Notes#
Pigsty v4.4.0 is a maintenance release focused on PostgreSQL 18.4, preview support for PostgreSQL 19 beta, 531 extensions, kernel variant updates, and broader platform coverage.
Released on 2026-07-10. See the GitHub release and the complete changes since v4.3.0.
Highlights
- PostgreSQL 18.4 / 19 beta: PostgreSQL 18.4 is now the production default, with a minimal PostgreSQL 19 beta template available for evaluation.
- 531 extensions and kernel updates: The extension catalog adds 21 extensions, with major PostgreSQL kernel variants updated across the supported platform matrix.
- Pig 1.5.1 and safer operations: New clone, fork, and PITR workflows, plus automatic VIP interface discovery, pgBackRest Zstandard compression, and dedicated Patroni log collection.
- Security, applications, and tooling: Hardened handling of sensitive configuration and repository security automation, new application templates, a redesigned infrastructure portal, and optional Codex support.
- Platform validation: All 14 offline deployment tests across seven operating-system baselines on
x86_64andaarch64passed. - Offline artifacts: The Community Edition publishes six dual-architecture offline bundles on GitHub for Debian 13, EL 10, and Ubuntu 24.04; prebuilt bundles for the other validated baselines are available through the Professional Edition.
Compatibility Changes
- Newly generated pgBackRest configurations now use
compress-type=zst; preserve any intentional local customizations before rendering them again. #744 - Patroni logs now use
/pg/log/patroniandjob=patroni; custom log queries and alerting rules that use the old syslog selector must be updated accordingly. - VIP interface defaults have changed to
auto, dnsmasq records have moved to/etc/dnsmasq.d/pigsty, and Pigsty now manages/etc/default/haproxy; nonstandard network environments should preserve explicit overrides. - The default etcd backend quota has been reduced from 16 GiB to 8 GiB; check current backend usage before applying the new configuration.
pigautomation scripts must pass-y/--yeswhen running destructive commands; bothpig pb restoreandpig pitrrequire exactly one explicit recovery target. See thepigv1.5 release notes.- Supabase Analytics now uses the
_supabasedatabase and_analyticsschema; create these objects before switching an existing deployment to the new stack.
Security and Operations
- The
pg-pitrwrapper adds safer recovery-target selection, timeline and dry-run support, and stronger checks for unsafe recovery targets. - Ansible output no longer exposes sensitive application configuration, generated
.envfiles are set to mode0600, and Grafana no longer prints the administrator password. - The
dbsusudo policy adds controlled log-viewing permissions; the repository also adds a security policy, CodeQL, Dependabot, pinned GitHub Actions dependencies, and release-signing automation.
Applications and Tooling
- Added Immich, Maybe, and JumpServer templates, and updated Supabase, Dify, InsForge, Registry, Jupyter, Kong, Odoo, Teable, Mattermost, and related startup scripts.
- Redesigned the bilingual Chinese/English infrastructure portal; the experimental VIBE module can install Codex CLI on demand, while Claude Code remains its default managed coding agent.
- Removed the legacy FerretDB Compose template; the FERRET module remains available.
Bug Fixes
- Fixed EL10 PostgreSQL/libpq package-provider conflicts, EPEL path handling, and PGDG minor-version repository rules. #752
bootstrapnow reuses an existing/wwwdirectory, and Redis Sentinel HA password rendering has been fixed. #753 #748- Corrected RPM package names and package groups for
pg_http,pg_gzip,apache-age, andodbc_fdw. #750 - Prevented services from starting unexpectedly during package installation on Debian and Ubuntu, and improved EL9 aarch64 Patroni package handling.
- Fixed VirtualBox private-network routing and default-interface selection.
- Fixed shell compatibility and Vector log-lifecycle issues, along with PG 19
io_workers, Teable HBA, and several application runtime defaults.
PostgreSQL and Extension Package Changes
This release adds 21 extensions, refreshes the PostgreSQL 18.4 package set, introduces a PostgreSQL 19 beta template, and updates the major kernel variants. The versions below follow the final repository metadata; versions included in offline bundles were also cross-checked against the v4.4.0 artifacts. PostgreSQL major-version ranges indicate coverage in the extension catalog and software repositories.
PostgreSQL RPM Changes · PostgreSQL DEB Changes · Infrastructure Package Changes
| Package | Old Version | New Version | Notes |
|---|---|---|---|
polardb-17 | 17.9.1.0 | 17.10.1.0 | PG 17; new RPM package |
agensgraph-17 | 2.16.0 | 2.17.0 | PG 17.10 |
openhalodb-14 | 1.0-beta | 1.0-2 | OpenHaloDB |
babelfish-17 | 5.4.0 | 5.4.0 | PG 17.7; rebuilt |
babelfish-18 | - | 6.0.0 | PG 18.3 |
pgedge | 17.9 / 18.3 | 15.18 / 16.14 / 17.10 / 18.4 | Added PG 15/16; updated PG 17/18; Spock 5.0.10 |
ivorysql-18 | 5.0 | 5.4 | PG 18; new RPM package |
cloudberry | 2.1.0-1 | 2.1.0-2 / 2.1.0-3 | DEB/RPM rebuild; RPM path is /usr/cloudberry |
cloudberry-backup | 2.1.0-1 | 2.1.0-2 / 2.1.0-3 | Backup subpackage |
cloudberry-pxf | 2.1.0-1 | 2.1.0-2 / 2.1.0-3 | PXF subpackage |
pg_ducklake | - | 1.0.0 | PG 14-18 |
psql_bm25s | - | 0.4.13 | BM25 search; PG 17-18 |
mongo_fdw | 5.5.3 | 5.5.3 | New DEB package; PGDG RPM already available; PG 14-18 |
multicorn | 3.2 | 3.2 | New DEB package; PGDG RPM already available; PG 14-18 |
pg_orca | - | 1.0.0 | PG 18 only |
pg_sorted_heap | - | 0.14.0 | PG 16-18 |
pg_stl | - | 1.0.0 | PG 16-18 |
fsm_core | - | 1.1.0 | PG 15-18 |
pg_projection | - | 1.0.0 | PG 14-18 |
graph | - | 0.1.7 | PG 14-18 |
jsonschema | - | 0.1.9 | PG 14-18 |
pg_durable | - | 0.2.2 | PG 14-18 |
pg_stat_log | - | 0.1 | PG 18 only |
pg_stat_plans | - | 2.1.0 | PG 16-18 |
pg_task | 1.0.0 | 2.1.29 | PG 14-18; fixes pcre2grep dependency |
pg_stat_backtrace | - | 1.0.0 | PG 14-18; depends on libunwind |
pg_mockable | - | 1.1.0 | PG 14-18 |
db2fce | - | 0.0.17 | PG 14-18 |
pg_uuid_v8 | - | 1.0.0 | PG 14-18 |
pg_extra_time | 2.0.0 | 2.1.0 | PG 14-18 |
pg_pinyin | 0.0.2 | 0.0.4 | PG 14-18 |
passwordpolicy | - | 2.0.5 | PG 14-18 |
pgdisablelogerror | - | 1.0 | PG 14-18 |
plpgsql_wrap | - | 1.0 | PG 14-18 |
timescaledb | 2.26.4 | 2.28.2 | PG 15-18 |
documentdb | 0.110 | 0.113 | PG 15-18 |
citus | 14.0.0-4 | 14.1.0 | PG 16-18 |
pgvector | 0.8.2 | 0.8.4 | PG 14-18 |
orioledb | 1.7-beta15 | 1.8-beta16 | Built for PG 16/17/18 |
pg_search | 0.23.1 | 0.24.0 | PG 15-18 |
pg_textsearch | 1.1.0 | 1.2.0 | BM25 full-text search; PG 17-18 |
storage_engine | 1.3.4 | 2.4.0 | Updated to PGXN 2.x; PG 15-18 |
pg_clickhouse | 0.2.0 | 0.3.2 | PGXN version update; ClickHouse integration |
provsql | 1.2.3 | 1.10.0 | PGXN version update; PG 14-18 |
pgclone | 4.0.0 | 4.3.2 | PGXN version update; PG 14-18 |
biscuit | 2.2.2 | 2.4.0 DEB / 2.4.1 RPM | PG 16-18 |
pgmnemo | 0.7.2 | 0.12.1 | PG 14-18 |
rdf_fdw | 2.5.0 | 2.6.0 | PG 14-18; libcurl compatibility patch |
roaringbitmap | 1.1.0 | 1.2.0-2 | PG 14-18; fixes llvm-lto packaging |
plpgsql_check | 2.9.0 | 2.9.2 | PG 14-18 |
timescaledb_toolkit | 1.22.0 | 1.23.0 | PG 15-18; pgrx 0.18.1 |
wrappers | 0.6.0 | 0.6.1 | PG 14-18; pgrx 0.18.1 |
pgrdf | 0.5.0 | 0.6.4 | PG 14-17; pgrx 0.18.1 |
pg_graphql | 1.5.12 | 1.6.1 | PG 14-18; pgrx 0.18.1 |
pg_anon | 3.0.13 | 3.1.1 | PG 14-18; pgrx 0.18.1 |
pg_kazsearch | 2.0.0 | 2.2.0 | PG 16-18; pgrx 0.18.1 |
pg_session_jwt | 0.4.0 | 0.5.0 | PG 14-18; pgrx 0.18.1 |
pg_tzf | 0.2.4 | 0.3.0 | PG 14-18; pgrx 0.18.1 |
pg_vectorize | 0.26.1 | 0.26.2 | PG 14-18; pgrx 0.18.1 |
pglinter | 1.1.2 | 2.0.0 | PG 14-18; pgrx 0.18.1 |
pgmqtt | 0.1.0 | 0.3.0 | PG 14-18; pgrx 0.18.1 |
etcd_fdw | 0.0.0 | 0.0.1 | PG 14-18; pgrx 0.18.1 |
pg_http | 1.7.0 | 1.7.1 | PG 14-18; RPM renamed to pgsql_http_$v |
pg_gzip | 1.0.0 | 1.1.0 | PG 14-18; RPM renamed to pgsql_gzip_$v |
age | 1.7.0 | 1.7.0 | PG 17-18; RPM renamed to age_$v |
pg_trickle | 0.40.0 | 0.81.0 | PG 18 only |
re2 | 0.1.1 | 0.4.0 | PG 16-18 |
pg_background | 1.9.2 | 2.0.2 DEB / 2.0 RPM | PG 14-18 |
firebird_fdw | 1.4.1 | 1.4.2 | PG 14-18 |
pg_net | 0.20.2 | 0.20.3 | DEB and EL10 RPM updated; EL8/9 RPM stays at 0.9.2 |
pg_dirtyread | 2.7 | 2.8 | PG 14-18 |
pg_stat_ch | 0.3.6 | 0.3.6 | PG 16-18; rebuilt |
pggraph | 0.1.5 | 0.1.7 | PG 14-18 |
pgsql_tweaks | 1.0.2 | 1.0.5 | PG 14-18; PGDG RPM also contains 1.0.3 |
pgfincore | 1.3.1 | 1.4.0 | PG 14-18 |
toastinfo | 1.5 | 1.7 | PG 14-18 |
pg_ivm | 1.14 | 1.15 DEB / 1.14 RPM | PG 14-18 |
timeseries | 0.2.0 | 0.2.1 | PG 14-18 |
Infrastructure Package Changes
| Package | Old Version | New Version | Notes |
|---|---|---|---|
pig | 1.4.1 | 1.5.1 | |
pg_exporter | 1.2.2 | 1.3.0 | |
pgschema | 1.9.0 | 1.12.0 | |
pgstream | 1.0.1 | 1.1.1 | |
pg-hardstorage | - | 1.0.8 | |
codex | 0.125.0 | 0.144.1 | |
claude | 2.1.123 | 2.1.206 | |
opencode | 1.14.30 | 1.17.18 | |
agentsview | 0.26.0 | 0.37.5 | |
genai-toolbox | 1.1.0 | 1.6.0 | Package name is mcp-toolbox |
crush | 0.64.0 | 0.84.0 | |
code | 1.118.1 | 1.128.0 | |
code-server | 4.117.0 | 4.127.0 | |
victoria-metrics | 1.142.0 | 1.147.0 | |
victoria-metrics-cluster | 1.142.0 | 1.147.0 | |
vmutils | 1.142.0 | 1.147.0 | |
victoria-logs | 1.50.0 | 1.51.0 | |
vlagent | 1.50.0 | 1.51.0 | |
vlogscli | 1.50.0 | 1.51.0 | |
victoria-traces | 0.8.2 | 0.9.4 | |
prometheus | 3.11.3 | 3.13.1 | |
alertmanager | 0.32.1 | 0.33.1 | |
pushgateway | 1.11.2 | 1.11.3 | |
node_exporter | 1.11.1 | 1.11.1 | Backfilled the tarball cache; corrected version metadata |
redis_exporter | 1.82.0 | 1.86.0 | |
mongodb_exporter | 0.50.0 | 0.51.0 | |
grafana | 13.0.1 | 13.1.0 | |
grafana-victorialogs-ds | 0.26.3 | 0.29.0 | |
grafana-victoriametrics-ds | 0.24.0 | 0.25.2 | |
vector | 0.55.0 | 0.56.0 | |
minio | 20260417000000 | 20260618000000 | |
seaweedfs | 4.22 | 4.39 | |
rustfs | 1.0.0-b1 | 1.0.0-b8 | Prerelease line |
duckdb | 1.5.2 | 1.5.4 | |
kafka | 4.2.0 | 4.3.1 | |
etcd | 3.6.10 | 3.6.13 | |
restic | 0.18.1 | 0.19.1 | |
juicefs | 1.3.1 | 1.4.0 | |
tigerbeetle | 0.17.2 | 0.17.9 | |
tigerfs | 0.6.0 | 0.7.0 | |
caddy | 2.11.2 | 2.11.4 | |
cloudflared | 2026.2.0 | 2026.7.1 | |
headscale | 0.28.0 | 0.29.2 | |
v2ray | 5.48.0 | 5.51.2 | |
nodejs | 24.15.0 | 24.18.0 | |
golang | 1.26.2 | 1.26.5 | |
hugo | 0.161.1 | 0.164.0 | |
uv | 0.11.8 | 0.11.28 | |
rclone | 1.73.5 | 1.74.4 | |
asciinema | 3.2.0 | 3.2.1 | |
stalwart | 0.16.2 | 0.16.12 | |
maddy | 0.9.3 | 0.9.5 | |
dblab | 0.38.0 | 0.43.0 | |
npgsqlrest | 3.12.0 | 3.20.0 | |
postgrest | 14.10 | 14.14 | |
sabiql | 1.11.1 | 1.14.0 | |
pev2 | 1.21.0 | 1.22.0 | |
rainfrog | 0.3.18 | 0.3.19 |
Validation and Checksums
All 14 offline deployment tests covering EL9/10, Debian 12/13, and Ubuntu 22/24/26 across x86_64 and aarch64 are complete, with failed=0 and unreachable=0 in every case; EL8 remains available for online installation only.
The MD5 checksums below cover all 14 validated artifacts. Six Community Edition artifacts are uploaded to GitHub, while the other eight are delivered through the Professional Edition; GitHub records SHA-256 digests for the uploaded Community Edition artifacts.
7de8b932412f1863fd9c033a7be355d7 pigsty-pkg-v4.4.0.d12.aarch64.tgz
2e5006a8d35eb1c087dc0ed11cf14d14 pigsty-pkg-v4.4.0.d12.x86_64.tgz
955308c00d3890f6e82a6a83bc624760 pigsty-pkg-v4.4.0.d13.aarch64.tgz
350f31c66de0aafff3bd91c2c9d740a0 pigsty-pkg-v4.4.0.d13.x86_64.tgz
0b4817a8edbab0bdf37ecee730fb0412 pigsty-pkg-v4.4.0.el10.aarch64.tgz
4584a61e4456749e68d86e4817cfe526 pigsty-pkg-v4.4.0.el10.x86_64.tgz
21621daf510a532829c36464d48f9198 pigsty-pkg-v4.4.0.el9.aarch64.tgz
504afd5030e2738a25e1b4c570d0e654 pigsty-pkg-v4.4.0.el9.x86_64.tgz
461c999424dee587ca33fe1a63df40d7 pigsty-pkg-v4.4.0.u22.aarch64.tgz
20ccc5ab8f9f4648b05bcd304f9fb5fc pigsty-pkg-v4.4.0.u22.x86_64.tgz
d092c48ee55116ed5e2c99a3d909ccdd pigsty-pkg-v4.4.0.u24.aarch64.tgz
24fa5399d8421305961fcaf91325b382 pigsty-pkg-v4.4.0.u24.x86_64.tgz
36f69b699d8b3041d35384970e157631 pigsty-pkg-v4.4.0.u26.aarch64.tgz
330047d117b20f04317dce506edd5d9a pigsty-pkg-v4.4.0.u26.x86_64.tgz
3077203c0c656ec99abc32b227f6566b pigsty-v4.4.0.tgz
