Blog

• 1: Article
  • 1.1: Pigsty v4.5: 575 Extensions, Silo, Valkey, Kafka, and MySQL
  • 1.2: SOW: Postpartum Care for 100,000 Packages
  • 1.3: Pigsty v4.4: From Integration to Distribution
  • 1.4: Instantly Clone PostgreSQL Databases—No Black Magic Required
  • 1.5: What Is a PostgreSQL Distribution?
  • 1.6: Pigsty v4.3: 510 Extensions & Ubuntu 26
  • 1.7: Give DBA Agents a Body
  • 1.8: Put Your AI Agent's State in a Database
  • 1.9: Pigsty Goes Global: 1.44M Visitors, Zero Ad Revenue
  • 1.10: Pigsty v4.2: 12 Kernels in Bloom
  • 1.11: Pigsty v4.1: Speed Is the Moat
  • 1.12: The Agent Moat: Runtime
  • 1.13: Pigsty v4.0: Into the AI Era
  • 1.14: From AGPL to Apache: Why I Changed Pigsty's License
  • 1.15: Pigsty v3.7: Magneto Award and PG18 Ready
  • 1.16: Forging a China-Rooted, Global PostgreSQL Distro
  • 1.17: Pigsty v3.6: The Ultimate PostgreSQL Distribution
  • 1.18: Pigsty v3.5: 4K Stars, PG18 Beta, 421 Extensions
  • 1.19: Pigsty v3.4: PITR Enhancement, Locale Best Practices, Auto Certificates
  • 1.20: Pigsty v3.3: 404 Extensions, Turnkey Apps, New Website
  • 1.21: Pigsty v3.2: The pig CLI, Full ARM Support, Supabase & Grafana Enhancements
  • 1.22: Pigsty v3.1: One-Click Supabase, PG17 Default, ARM & Ubuntu 24
  • 1.23: Pigsty v3.0: Pluggable Kernels & 340 Extensions
  • 1.24: Self-Hosting Dify with PG, PGVector, and Pigsty
  • 1.25: Pigsty v2.7: The Extension Superpack
  • 1.26: Pigsty v2.6: PostgreSQL Crashes the OLAP Party
  • 1.27: Pigsty v2.5: Ubuntu & PG16
  • 1.28: Pigsty v2.4: Monitor Cloud RDS
  • 1.29: Pigsty v2.3: Richer App Ecosystem
  • 1.30: Pigsty v2.2: Monitoring System Reborn
  • 1.31: Pigsty v2.1: Vector + Full PG Version Support!
  • 1.32: Pigsty v2.0: Open-Source RDS PostgreSQL Alternative
  • 1.33: Pigsty v1.5: Docker Application Support, Infrastructure Self-Monitoring
  • 1.34: Pigsty v1.4: Modular Architecture, MatrixDB Data Warehouse Support
  • 1.35: Pigsty v1.3: Redis Support, PGCAT Overhaul, PGSQL Enhancements
  • 1.36: Pigsty v1.2: PG14 Default, Monitor Existing PG
  • 1.37: Pigsty v1.1: Homepage, Jupyter, Pev2, PgBadger
  • 1.38: Pigsty v1.0: GA Release with Monitoring Overhaul
  • 1.39: Ready-to-Use PostgreSQL Distribution: Pigsty
  • 1.40: Pigsty v0.9: CLI + Logs
  • 1.41: Pigsty v0.8: Service Provisioning
  • 1.42: Pigsty v0.7: Monitor-Only Deployments
  • 1.43: Pigsty v0.6: Provisioning Upgrades
  • 1.44: Pigsty v0.5: Declarative DB Templates
  • 1.45: Pigsty v0.4: PG13 and Better Docs
  • 1.46: Pigsty v0.3: First Public Beta
• 2: Release
  • 2.1: Pigsty v4.5.0
  • 2.2: Pigsty v4.4.0
  • 2.3: Pigsty v4.3.0
  • 2.4: Pigsty v4.2.2
  • 2.5: Pigsty v4.2.1
  • 2.6: Pigsty v4.2.0
  • 2.7: Pigsty v4.1.0
  • 2.8: Pigsty v4.0.0
  • 2.9: Pigsty v3.7.0
  • 2.10: Pigsty v3.6.1
  • 2.11: Pigsty v3.6.0
  • 2.12: Pigsty v3.5.0
  • 2.13: Pigsty v3.4.1
  • 2.14: Pigsty v3.4.0
  • 2.15: Pigsty v3.3.0
  • 2.16: Pigsty v3.2.2
  • 2.17: Pigsty v3.2.1
  • 2.18: Pigsty v3.2.0
  • 2.19: Pigsty v3.1.0
  • 2.20: Pigsty v3.0.4
  • 2.21: Pigsty v3.0.3
  • 2.22: Pigsty v3.0.2
  • 2.23: Pigsty v3.0.1
  • 2.24: Pigsty v3.0.0
  • 2.25: Pigsty v2.7.0
  • 2.26: Pigsty v2.6.0
  • 2.27: Pigsty v2.5.1
  • 2.28: Pigsty v2.5.0
  • 2.29: Pigsty v2.4.1
  • 2.30: Pigsty v2.4.0
  • 2.31: Pigsty v2.3.1
  • 2.32: Pigsty v2.3.0
  • 2.33: Pigsty v2.2.0
  • 2.34: Pigsty v2.1.0
  • 2.35: Pigsty v2.0.2
  • 2.36: Pigsty v2.0.1
  • 2.37: Pigsty v2.0.0
  • 2.38: Pigsty v1.5.1
  • 2.39: Pigsty v1.5.0
  • 2.40: Pigsty v1.4.1
  • 2.41: Pigsty v1.4.0
  • 2.42: Pigsty v1.3.1
  • 2.43: Pigsty v1.3.0
  • 2.44: Pigsty v1.2.0
  • 2.45: Pigsty v1.1.1
  • 2.46: Pigsty v1.1.0
  • 2.47: Pigsty v1.0.1
  • 2.48: Pigsty v1.0.0
  • 2.49: Pigsty v0.9.1
  • 2.50: Pigsty v0.9.0
  • 2.51: Pigsty v0.8.0
  • 2.52: Pigsty v0.7.0
  • 2.53: Pigsty v0.6.0
  • 2.54: Pigsty v0.5.2
  • 2.55: Pigsty v0.5.1
  • 2.56: Pigsty v0.5.0
  • 2.57: Pigsty v0.4.0
  • 2.58: Pigsty v0.3.0
  • 2.59: Pigsty v0.0.5
  • 2.60: Pigsty v0.0.4
  • 2.61: Pigsty v0.0.3
  • 2.62: Pigsty v0.2.0
  • 2.63: Pigsty v0.1.0
• 3: Design

1 - Article

This column collects every article in VONNG’s dedicated Pigsty section, plus articles in other columns whose front matter explicitly carries the Pigsty tag. Original page resources and available English translations are preserved.

1.1 - Pigsty v4.5: 575 Extensions, Silo, Valkey, Kafka, and MySQL

Originally published on VONNG.

GitHub Release | Release Note

Pigsty v4.5 is officially out. At the end of the previous release, I said there might be a transitional v4.5 before 5.0. Here it is—except this “transitional” release ended up more packed than many full-fledged major releases.

Here is the short version of what is new in v4.5:

• 575 PostgreSQL extensions: up from 531, with new additions including pg_lake, pg_jieba, and plruby.
• Silo object storage: the MINIO module has switched engines and now runs Silo, Pigsty’s own maintained MinIO fork.
• Valkey: the REDIS module adds Valkey as an engine. One parameter switches it over while preserving the inventory, monitoring, and dashboards.
• Kafka module: a new pilot module with native KRaft orchestration for multiple clusters, dynamic membership, SCRAM/TLS, and four monitoring dashboards.
• MySQL module: yes, MySQL. You read that right. It supports MySQL 8.4 LTS as either a standalone instance or a three-node InnoDB Cluster, also as a pilot module.
• And a long tail of smaller but useful changes: explicit cluster identities, safer removal workflows, pg_exporter 1.4, the SOW repository tool, 51 configuration templates, and more.

Let’s go through them in order.

575 Extensions

Every release gets a new extension count. This time it is 575—46 additions and two removals since v4.4’s 531, for a net gain of 44. The full catalog is still available in the extension list. Here are a few of the more notable arrivals:

• The complete pg_lake suite: the lakehouse stack that Snowflake open-sourced after acquiring Crunchy Data. It uses DuckDB as a vectorized execution engine and brings Iceberg and Parquet directly into PostgreSQL. This is the most important new development in the PostgreSQL data-lake ecosystem this year, and Pigsty packaged it immediately for PostgreSQL 16–18. On the RPM side, it is currently available only for EL 9/10.
• pg_jieba and pg_cjk_parser: Chinese and CJK tokenizers. Anyone building Chinese full-text search knows what this means—people who used to compile pg_jieba themselves can finally stop.
• plruby: the Ruby procedural language, packaged together with its three type-conversion subextensions for hstore, jsonb, and ltree. Another piece of the procedural-language puzzle is in place. I am also curious who will actually write stored procedures in Ruby.
• pgmemento: auditing and data-change tracking implemented entirely in SQL, giving tables a complete timeline.
• online_advisor: recommends indexes online based on queries that actually run.
• pg_turbovec, pgcontext, and pg_tiktoken_c: more depth for vector search and RAG, joined by pgmnemo 0.16 for agent memory. The AI toolkit keeps getting thicker.
• There are also more specialized additions such as pgwasm for WebAssembly, postbis for bioinformatics sequences, qdgc for geographic grids with a PostGIS subextension, and pg_vault_tde for transparent encryption backed by Vault.

Beyond the additions, this cycle rebuilt almost every Rust extension against pgrx 0.19.1. Many package version numbers look unchanged, but the entire build matrix was rerun behind the scenes. An unchanged version number does not mean no work happened.

Two extensions were removed: pg_analytics, which upstream has archived, and spat, a discontinued alpha project. Five others—emailaddr, explain_ui, oidc_validator, pg_summarize, and smlar—were removed from the default installation groups because upstream provides no license. The packages remain available, but you must install them explicitly and assess the licensing and redistribution boundaries yourself. A distribution can package software for you; it cannot assume your compliance obligations.

Routine upgrades continued as well: Citus 14.2, TimescaleDB 2.29.1, pgvector 0.8.6, pg_search 0.25.2, DocumentDB 0.114, pg_partman 5.5, pgmq 1.12, and more. The complete package change log runs for more than 200 lines; see the release note rather than making me reproduce it here.

Silo: A New Engine for Object Storage

Long-time readers know the MinIO story. Upstream reduced its admin console to little more than a login page, the community edition was effectively abandoned, and I forked it to keep it alive and patch CVEs. I wrote about that in MinIO Is Dead and Two Months into Maintaining a MinIO Fork. That fork eventually got its own name: Silo. Put a grain silo beside the Pigsty, add the pig package manager and the sow repository tool, and the whole family is together.

v4.5 takes that transition to its conclusion: the MINIO module now deploys Silo, and only Silo. The only valid value for minio_type is currently silo. Compatibility should not be a concern: the S3 and Admin APIs, /minio/* routes, MINIO_* environment variables, and on-disk data format all remain unchanged. Only the package, binary, and systemd service names have changed. For existing users, this is closer to swapping in an engine with a new badge while leaving the chassis and controls untouched.

Protocol compatibility does not validate the migration for you, of course. Before switching production object storage, you still need backups, a rollback plan, and real read/write verification.

The Silo transition comes with several related improvements:

• Startup now verifies three signals: the systemd Invocation ID, ActiveState, and Silo cluster health. It waits up to roughly 600 seconds and no longer mistakes the state of an old process for a successful start of the current one.
• Object-storage nodes are grouped by minio_cluster identity. One inventory can declare multiple clusters, each with its own minio_alias and minio_endpoint.
• The ha/trio high-availability template replaces its single-node object store with a three-node, single-drive Silo cluster using EC:1, exposed on port 9002 through a VIP and HAProxy.
• Distributed Silo requires /data/minio to be a separate filesystem. A normal directory on the root filesystem is rejected outright—this guardrail is there to prevent the all-too-common mistake of putting production object storage on the root volume.

What about RustFS? We did implement a RustFS backend during this development cycle, then pulled it before release. It is not quite ready; we will revisit it once it reaches a genuinely stable GA release. The repository still contains the RustFS 1.0.0-rc.1 package if you want to experiment, but it is not a backend supported by the v4.5 MINIO module.

Valkey: An Alternative to Redis

I have written plenty about the Redis licensing drama, including Redis Going Non-Open-Source Is a Disgrace to “Open Source” and Public Clouds. Redis 8 later returned under the AGPL, but the community fork Valkey has developed into an ecosystem of its own, backed by the Linux Foundation and packaged by every major distribution. Users kept asking whether Pigsty could run Valkey.

Now it can: set redis_type: valkey. That is all it takes.

We deliberately designed this as a transparent switch. Pigsty installs valkey-server and valkey-cli, while configuration paths, data directories, service names, monitoring jobs, and module parameters all stay under the redis namespace. Existing inventories, dashboards, and alert rules require no changes. The engine choice applies per cluster, so do not mix engines within one cluster. Before converting an existing Redis cluster to Valkey, rehearse in a test environment and verify data and replication compatibility for yourself. For an idea of how deep the official-package rabbit hole goes, see A Packaging Patch Has Been Corrupting Valkey’s Memory Accounting Since 2017.

The Redis/Valkey systemd units now use Type=notify, and the startup timeout has been extended to 1,800 seconds so systemd no longer kills large instances while they load data. Topology construction, password handling, and removal safeguards were hardened as well.

Kafka: From Package to Module

Why should a PostgreSQL distribution manage Kafka? Because in real data architectures, a Kafka cluster is very often sitting next to PostgreSQL. Change data capture, message queues, and event streams all need to run somewhere. Pigsty already shipped Kafka packages—and kafka_fdw—but deployment was manual. v4.5 adds a complete KAFKA module.

The module is based on Kafka 4.3, runs pure KRaft with no ZooKeeper, and provides orchestration built from scratch in the Pigsty style:

• kafka_cluster and kafka_seq define cluster identity. Nodes can take combined, broker, or controller roles, and one inventory can contain multiple Kafka clusters.
• Dynamic KRaft quorum management covers controller onboarding, broker admission, member retirement, and three-stage replacement of failed members, all as standardized playbook workflows.
• Security includes SCRAM-SHA-512 and TLS. Credentials and certificates can be rotated, followed automatically by partition health checks.
• Monitoring is comprehensive: JMX Exporter plus Kafka Exporter, alert rules, and four Grafana dashboards for Overview, Instance, Topic, and Consumer views.
• Dangerous operations follow strict rules. kafka-rm.yml requires an explicit scope through -l, then validates data directories and surviving nodes before stopping services. An incomplete --limit is rejected outright, eliminating the chance of touching only half the quorum by mistake.

To try it, use the ready-made conf/demo/kafka.yml template.

Kafka is currently a pilot module. Keep one architectural constraint in mind: the Kafka protocol requires clients to connect directly to every broker, so its data plane cannot sit behind HAProxy, a VIP, or a Layer 4 load balancer. That is not a Pigsty limitation; it is simply how Kafka works.

MySQL: Bet You Didn’t See That Coming

What happened to Postgres Is Eating the Database World? Why turn around and ship a MySQL module in Pigsty?

Easy. Even world domination has an order of operations. The installed base of MySQL is enormous. Many users put new systems on PostgreSQL while still having to maintain legacy MySQL applications. Others have committed to migrating, but still need someone to operate dozens of MySQL clusters until that migration finishes. Instead of making them build a separate monitoring, backup, and high-availability stack for legacy systems, Pigsty can manage them on the same foundation. Monitoring, alerting, backup, recovery, and cluster orchestration are generic infrastructure anyway.

Bring them into the fold first; digest them later. Perfectly reasonable.

The new pilot MYSQL module in v4.5 looks like this:

• It targets MySQL 8.4 LTS, using packages from the official community repository together with Percona XtraBackup.
• It supports either a standalone instance or a three-node InnoDB Cluster using Group Replication, with MySQL Shell and MySQL Router. Cluster membership must be exactly one or three nodes; nothing else is accepted.
• Users and databases are provisioned declaratively through mysql_users and mysql_databases. Scheduled full backups use XtraBackup, and TLS is enabled by default.
• mysql_parameters exposes tunables, but settings reserved for replication, TLS, and the platform are protected. Prefixes such as loose_ and skip_ cannot bypass those protections.
• Five dashboards cover Overview, Cluster, Instance, Replication, and Alert views. mysqld_exporter plugs into the unified service-discovery and alerting system.
• The mysql-rm.yml removal playbook is the most conservative of all the modules: if a target host has no MySQL identity, it fails immediately rather than “helpfully” cleaning anything up.

The demo template is conf/demo/mysql.yml. If what you really want is for PostgreSQL to speak the MySQL protocol, Pigsty also offers OpenHalo. As for whether PostgreSQL or MySQL is better, I will leave that for another essay: PostgreSQL vs. MySQL in 2026.

The Rest of the List

Those are the headline changes. Here are the smaller ones still worth knowing about.

The FERRET Module Is Split Up

The standalone FERRET module and its mongo.yml playbook have been removed. MongoDB compatibility is now divided into two layers: PostgreSQL with the DocumentDB extension provides the data layer, configured through the conf/mongo.yml template, while FerretDB runs as a Docker application and provides the protocol layer. The old ferretdb systemd service, dedicated monitoring, and dashboards are no longer included. This makes the division of responsibility clearer: data belongs to the database, and protocol translation belongs to the container.

Safer Orchestration

This release invests heavily in making sure playbooks do not cause collateral damage:

• Initialization and removal playbooks for PGSQL, REDIS, MINIO, KAFKA, and MYSQL now select members by explicit cluster identity—parameters such as pg_cluster—instead of relying only on inventory group names. A playbook run against the wrong group skips unrelated hosts rather than “helpfully” installing something on them.
• PITR and removal now delete only the etcd subtree bounded by /<cluster-name>/. Previously, if one cluster name was a prefix of another—pg-test and pg-test2, for example—cleanup could delete the neighboring cluster’s metadata. It cannot anymore.
• The initial pgBackRest backup writes its marker file only after the backup command actually succeeds. No more markers claiming that a backup exists when it does not.
• Removal workflows across all modules now stop services before deleting data. Kafka, MySQL, and object storage also perform additional checks on data directories, quorums, and surviving members.
• The full pgsql.yml playbook is now explicitly marked for first-time initialization only. It restarts Patroni/PostgreSQL and reapplies configuration and initialization SQL; it is not a day-to-day convergence tool. Do not rerun the whole playbook against a production cluster.
• DBSU SSH keys are exchanged among the actual cluster members, correctly covering cross-group topologies such as Citus. Pigsty-rendered systemd units now live consistently under /etc/systemd/system, and permissions are tighter for sensitive configuration and privileged files.

None of these changes is a new feature. Every one of them corresponds to a real class of production incident.

Observability

• The entire Grafana dashboard set was re-exported through the pig toolchain in Dashboard API v2 format. Four Kafka dashboards and five MySQL dashboards were added, while the Node, PGSQL, Redis, and Infra dashboards were refreshed.
• pg_exporter moves to the 1.4 series. It includes new PostgreSQL 19 collectors for subscriptions, recovery status, WAL, lock waits, and vacuum pressure. PostgreSQL 10 and later also gain a pg_xact_age transaction-age histogram, making the remaining distance to transaction ID wraparound directly visible.
• The MinIO/Silo dashboard now uses the Metrics V3 endpoint and drops high-cardinality samples labeled by bucket, substantially reducing time-series load for users with large numbers of buckets.

Repositories and Supply Chain

• Local software repositories are now generated by SOW, the repository-management tool previewed at the end of v4.4—named, naturally, after a mother pig. sow create --pigsty atomically generates DNF/APT metadata and a SHA-256 completion marker, and the old injected fake ModuleMD metadata is gone entirely.
• Offline package bundles can now include versioned source packages. Pigsty-built packages consistently use SHA-256-pinned inputs, SPDX license expressions, and the 1PGSTY release suffix.
• Exporter RPM names now use hyphens instead of underscores (node_exporter → node-exporter), with a smooth transition from the old names through Provides/Obsoletes.
• Mirror routing for China has been completely refreshed: Tencent Cloud is preferred, with Huawei Cloud, Alibaba Cloud, and USTC as platform-specific fallbacks.

Kernels and Platforms

• The default PostgreSQL version is now 18.6. Four standard Patroni templates add an output_plugin_libraries allowlist for logical decoding plugins—pgoutput, test_decoding, and wal2json—and Patroni automatically filters out the parameter on older PostgreSQL versions.
• The PostgreSQL 19 beta template now supports backups through pgBackRest 2.59. In v4.4, pgBackRest could not yet recognize the PostgreSQL 19 control file; PostgreSQL 19 test environments can now take proper backups.
• Percona PostgreSQL 18 TDE enables cluster mode. IvorySQL fixes default-database initialization and enables compatible WAL compression.
• OS baselines move to Rocky Linux 9.8/10.2, Debian 12.15/13.6, and Ubuntu 22.04.5/24.04.4/26.04. The Docker base image moves to Debian 13.6.
• There are now 51 configuration templates, including the new demo/kafka, demo/mysql, and the eight-node ha/octo simulation environment. ha/trio now uses a three-node Silo topology.
• The Vagrant root-disk size is configurable through root_disk, which defaults to 64 GB. disk continues to represent the additional /data data disk. VM login shells are now consistently Bash.

Component Versions

For the complete Infra and extension package change logs, see the release note.

Upgrade Notes

Before upgrading from v4.4, work through this list. Every item can bite:

1. minio_type accepts only silo: the protocol and disk format are compatible, but the package, binary, and service names have changed. Do not switch production object storage without tested backups and rollback procedures.
2. The ha/trio object-storage topology has changed: the new template uses three single-drive Silo nodes. You cannot expand an existing single-node pool in place simply by adding two machines; build a new cluster and migrate the data.
3. FERRET is split up: the mongo.yml playbook, mongo_* parameters, and dedicated dashboards are gone. Redeploy using the Mongo configuration template plus the Docker application.
4. Cluster identities are required: custom inventories must define pg_cluster, redis_cluster, minio_cluster, kafka_cluster, or mysql_cluster as appropriate on every target host.
5. pgsql.yml is only for initial provisioning: use precise tags for routine maintenance on initialized clusters; do not rerun the entire playbook.
6. Valkey is opt-in: without redis_type: valkey, Pigsty still deploys Redis. Engine changes apply per cluster; rehearse before switching.
7. SOW is now a hard dependency of REPO/CACHE: if an older offline bundle or local repository lacks sow 0.3.0, install it from the Pigsty Infra repository first.
8. Exporter RPMs have been renamed: external automation and private repositories should migrate from names such as node_exporter and redis_exporter to the new hyphenated package names.
9. Five unlicensed extensions left the default installation groups: environments that depend on emailaddr, explain_ui, oidc_validator, pg_summarize, or smlar must install them explicitly.
10. HAProxy unit semantics have changed: Pigsty no longer renders /etc/default/haproxy. If you override EXTRAOPTS, preserve the master-socket option and do not put -f in it.
11. make purge deletes ./data immediately: cleanup under the Docker directory no longer has a countdown and no longer accepts an external DATA variable. Check the target yourself before running it.
12. Kafka and MySQL are pilot modules: Kafka clients must be able to reach every broker directly; MySQL clusters must contain exactly one or three members.

Get v4.5

On a fresh, supported Linux node:

curl -fsSL https://repo.pigsty.io/get | bash -s v4.5.0
cd ~/pigsty
./bootstrap
./configure
./install.yml

Users in mainland China can replace repo.pigsty.io with repo.pigsty.cc. A production upgrade is not a matter of installing over the existing deployment: read the upgrade notes above, verify inventory identities, backups, and the actual runtime state, then roll out changes with an explicit -l scope.

Closing Thoughts

The theme of v4.4 was “from integration to distribution.” The theme of v4.5 might be “expanding boundaries.” Inside the PostgreSQL ecosystem, the extension catalog has grown to 575. Looking outward, object storage, caching, message queues, and even MySQL now share the same orchestration, monitoring, and delivery system.

Some may ask why a PostgreSQL distribution should cover so much. My view is that users never really want “a database”; they want an entire data infrastructure stack that can run their business. PostgreSQL sits at its core, but everything around that core—caches, object storage, message queues, and legacy databases—still needs to be managed to the same standards. Pigsty is a pigsty, after all, and it was never home to just one pig.

The next stop is 5.0. PostgreSQL 19 is due for release in September, and Pigsty 5.0 will arrive with full PostgreSQL 19 support. The groundwork is already in this release: PostgreSQL 19 metrics in pg_exporter, parameter placeholders in the Patroni templates, and backup support in pgBackRest. SOW, built in preparation for the enterprise edition’s conservative package repository, is now a formal dependency as well. See you in September.

GitHub Release | Release Note

1.2 - SOW: Postpartum Care for 100,000 Packages

Originally published on VONNG.

Today, let’s talk about Postpartum Care for Sows—a Chinese meme for the sort of absurdly specialized practical topic nobody expects to discuss. This time, the sow in question is my new open-source project, SOW.

When you maintain a PostgreSQL distribution, compiling the software is rarely the most painful part. The real pain is dealing with everything the build produces.

Pigsty maintains hundreds of components across multiple Linux distributions, CPU architectures, and major PostgreSQL versions. Multiply those combinations out, and the repository ends up with more than 100,000 artifacts: RPMs, DEBs, indexes, signatures, checksums, snapshots, and piles of metadata that exist only to keep package managers happy.

Users see apt install or dnf install. Maintainers see something else entirely. You update one package and must guarantee that the other 99,999 objects were not accidentally deleted. You change one index and must ensure that users around the world never catch the repository halfway through the cutover, with half the old state and half the new. At small scale, these look like scripting problems. At 100,000 artifacts, they abruptly become database, distributed systems, and software supply-chain problems.

That is why I built SOW, a self-contained APT/YUM repository manager written in Go.

If all you need is to turn a directory of RPMs and DEBs into a usable repository, one command is enough:

sow create /www/pigsty

For a repository you intend to maintain over time, SOW also provides Managed mode. It projects one package payload into multiple distribution views, records desired and built state, creates immutable snapshots, computes exact changesets, and publishes incremental updates to a filesystem or object store.

In one sentence: SOW puts the small job of “generating repository indexes” and the much larger job of “governing a long-lived software repository” into one self-contained binary.

I built this tool entirely to solve my own problems. But if you also maintain a large software repository spanning multiple Linux distributions, it should help you too—though admittedly, there probably aren’t many of us.

Why SOW?

The name deserves an explanation. We previously built a companion project, Pig—PostgreSQL Install Genius, the package manager for the PostgreSQL ecosystem. If a little Pig installs the packages, then the tool that produces, stores, organizes, and distributes those artifacts naturally has to be its mother: SOW.

It also expands neatly to Software Object Warehouse, a name that fits naturally into the software supply chain. Better yet, the pig metaphor has roots in industrial history. In traditional pig-iron casting, molten iron flowed down a central channel and branched into rows of smaller molds. The cooled ingots were called pigs, while the main runner that fed them was the sow. Seen from above, one large channel feeding rows of ingots looked like a sow nursing her piglets.

Why Build Another Repository Tool?

The immediate trigger was Pigsty’s offline installation. Pigsty first downloads the required RPMs and DEBs, then turns them into a local offline repository. Historically, RPM systems relied on createrepo_c, while Debian and Ubuntu relied on dpkg-dev. The output is only a few XML files, Packages indexes, and compressed metadata, yet preparing the toolchain pulls in hundreds of megabytes of dependencies.

That is cumbersome enough on Linux and even uglier on macOS. You have to start different Linux containers, mount the same directory into each one, run the RPM and DEB tools separately, then copy the results back. Bringing in hundreds of megabytes of tooling and a fleet of containers to generate a few megabytes of metadata is hardly elegant.

In Pigsty 4.5, I removed that clutter. SOW is a self-contained binary only a few megabytes in size. It runs directly on Linux and macOS, understands both RPM and DEB package formats, and implements the APT and DNF repository specifications. It has no daemon and requires no separate language runtime.

But installing fewer tools was only the surface problem. Four deeper problems convinced me to keep building SOW as the repository grew.

First, Hard Links Don’t Help in Object Storage

The same noarch RPM may appear in repositories for several architectures, and the same package may belong to beta, latest, and stable views. On a local disk, hard links let many paths share one inode. Upload them to Cloudflare R2, Alibaba Cloud OSS, or another object store, and every object key incurs real storage and upload costs. Identical content does not make the cloud treat those keys as one object.

Second, 100,000 Files Make Even a Comparison Expensive

A repository update may change only a few dozen packages, yet traditional synchronization tools often have to walk, compare, and verify more than 100,000 files to prove it. A full comparison can easily take more than ten minutes. The actual transfer may take seconds; almost all the time goes into proving that nothing changed.

Third, a Live Repository Must Never Expose a Half-Built State

An RPM repository is more than a directory of .rpm files. Clients read repomd.xml first, then follow it to primary, filelists, and the package payloads. APT has the same constraint: Release, InRelease, Packages, and by-hash files form a strict graph of references.

If you publish them in the wrong order, a client may see a new pointer before the object it references exists. To the maintainer, that is only a few seconds during an upload. To a user who happens to arrive during that window, it is an irreproducible 404, checksum failure, or aborted installation.

Fourth, Directories Have No Versions, but Distributions Need Them

The deeper problem surfaced when I wanted to add repository channels. How do you maintain beta, latest, and stable at the same time? Keep a monthly snapshot? Answer “which packages were added last Wednesday?” Roll back safely? Determine which old objects are no longer referenced by any snapshot and may be deleted?

You can script each requirement in isolation. Put them together, however, and those scripts metastasize into a shadow database with no transactions, schema, or audit trail. There are already tools such as createrepo_c, dpkg-scanpackages, reprepro, and aptly, along with general-purpose synchronization and object-storage tools. But I could not find a lightweight open-source tool that brought RPM and DEB support, a single package pool, immutable snapshots, atomic publishing, and incremental delivery into one clear model.

Fortunately, building your own tools has never been cheaper.

Two Levels of Complexity, Two Modes

SOW does not assume that every repository needs the same degree of governance. It splits the problem into Plain and Managed modes: small problems stay small, while large ones get the full state machine.

Plain: The Package Directory Is the Truth

Plain mode has one central command:

sow create /srv/repo

# Pigsty offline-repository compatibility mode
sow create /srv/repo --pigsty

The RPMs and DEBs in the directory are the sole source of truth. repodata/, Packages, and Packages.gz are projections that can be discarded and rebuilt at any time. SOW scans top-level packages concurrently. By default, it opens each package only once, computing its SHA-256, parsing it, and extracting every fact needed for rendering in the same pass before generating metadata for both repository formats.

The output first goes into a private staging area on the same filesystem. SOW validates it with its own parsers before replacing the public files. Finally, it compares the file set and stat snapshots again to confirm that no package was added, removed, or replaced during the build. It does not rehash every large package merely for extra reassurance.

Plain mode does not maintain an operation log or attempt heavyweight transaction recovery. If the process is interrupted, run the same sow create command again. The package directory is intact, the indexes are derived state, and rebuilding is cheaper than recovery.

With --pigsty, SOW also writes a repo_complete completion marker at the very end. Until that marker exists, consumers know the repository is not ready. It is a tiny but extremely useful commit protocol.

This mode solves Pigsty’s original problem: replace two toolchains and several containers with one small binary, then quickly produce a repository that real APT, DNF, and YUM clients can consume.

Managed: The Repository Is a State Machine, Not a Directory

A long-lived repository cannot look only at “what is in the directory now.” It must also know what you want, what it published successfully last time, and why the two differ.

SOW’s Managed model has four layers:

A Workspace is the configuration and discovery boundary. A Repository is the ownership boundary. A Dist is a named set of RPM or DEB members. An Architecture View is only a rendered result and does not own package payloads. The most important invariant is this: within one Repository, every package has exactly one canonical payload and no duplicates.

repo/pool/...                              canonical package payload
repo/dists/el9/x86_64/repodata/...         RPM metadata view
repo/dists/trixie/main/binary-amd64/...    APT metadata view

A noarch RPM or all DEB can appear in several architecture indexes without copying its payload. Beta and stable can reference the same package object without creating a second cloud object key. APT and DNF repositories can also live under the same directory hierarchy.

The boundary of “store only one copy” must be stated precisely: it is one Repository or one publication prefix, not an entire Workspace, bucket, or the whole world. SOW does not deduplicate implicitly across Repositories, because deduplication must not destroy ownership boundaries. Deleting one repository must never remove a shared object that another repository still needs.

Desired, Built, and Generation

Managed mode divides repository state into three concepts:

This distinction may sound academic. In practice, it exists specifically to handle failure.

Suppose you add 5,000 packages in one operation. Desired has changed, but the build is killed halfway through with SIGKILL. Without this separation, the system is left staring at a directory tree with no idea how far the update got. With it, SOW can state the truth: the intent has changed, the previous Built Generation remains intact and continues to serve users, and the new operation is awaiting recovery.

A Generation does not copy the entire repository. It stores an immutable manifest, metadata, and a set of package-payload references; many snapshots can reference the same Pool objects. The exact difference between two Generations is a Changeset: which payloads to add, which metadata to replace, which pointers to switch, and which old objects may be deleted after their retention period.

sow status  -r pigsty
sow changes -r pigsty
sow log     -r pigsty

Incremental synchronization therefore no longer begins with “scan 100,000 files again.” It begins with “compare two known Generations.”

The Secret to Atomic Cutovers: Move the Pointer Last

A software repository has no global transaction spanning multiple files or objects. SOW does not pretend otherwise. Instead, it turns publication order into a protocol whose safety can be reasoned about:

payload  →  metadata  →  pointer  →  delete
 objects      indexes      entry points   retired objects

First, place immutable package payloads. Next, write checksum-addressed metadata and by-hash indexes. Only after everything is in place does SOW switch the client entry points: repomd.xml, Release, and InRelease. Old objects may be deleted only after the old pointers no longer reference them and both retention and evidence gates have passed.

As a result, whenever a client follows an active pointer, the content it references already exists. Within one protocol view, readers see either the complete old Generation or the complete new one, never a torn tree.

On a local POSIX filesystem, this protocol relies on same-filesystem staging, fsync, atomic rename, stable-path locks, and a durable operation log. Before any Managed write command begins its own work, it checks for any unfinished prior operation and recovers it. Recovery decides whether to roll back or roll forward solely from evidence already persisted on disk. If the evidence conflicts, SOW stops and fails closed rather than offering a repair --force command that might guess wrong.

Object stores do not support atomic commits across several keys. SOW therefore persists a commit intent first, advances the protocol pointers in deterministic order, and records an Applied Checkpoint for each target. A filesystem target and an R2 target each have their own evidence; success on the former is never mistaken for success on the latter. If R2 lacks sufficient proof for a safe conditional delete, garbage collection reports candidates but does not risk deleting remote objects.

This is the essential difference between SOW and a single rclone sync command. Moving files is easy. The hard parts are knowing what to transfer, when the operation counts as committed, which direction recovery should take after failure, and what is truly safe to delete.

At 100,000 Objects, Performance Needs Proof

Most of the work in SOW 0.3 was not adding more features. It was making an already sound model work at real repository scale.

The Plain path now reads, hashes, and parses each package in a single pass, using bounded concurrency through --jobs. Identical input produces byte-for-byte identical metadata. When nothing needs updating, SOW returns no-op and does not replace a public inode merely to bump its timestamp.

The Managed path caches parsed “package facts” in SQLite, keyed by their immutable SHA-256 digest. A new package is fully authenticated and parsed once on ingestion. Later builds load facts in batches and compute the membership projection in memory. A warm build still walks the public namespace, but for unchanged Pool files it checks only the device, inode, size, mtime, and ctime fingerprint instead of reading every payload again. If the fingerprint drifts, SOW falls back to one authoritative SHA-256 pass and repairs the cache automatically. When you need a full cryptographic audit, run sow check explicitly.

Optimizations like these matter only when they show up in the numbers.

In the project benchmark, membership expansion for a Dist with 5,000 objects fell from about 4.1 seconds to 33 milliseconds. At 50,000 objects, the old implementation still had not finished after ten minutes; the new one takes about 300 milliseconds. Payload promotion now uses bounded, single-writer group commits, capped at 512 objects or 1 GiB per batch. This both reduces fsync storms and prevents file-descriptor use and recovery state from growing without bound as the repository expands.

These numbers are not there to decorate a benchmark slide. They simply demonstrate that once a repository truly holds 100,000 artifacts, “the state model is correct” is only the passing grade. Whether routine small changes remain cheap enough determines whether the tool stays viable over time.

Tearing Down V1 and Rebuilding from a Minimal End-to-End Core

SOW took a while to build. Midway through, I tore it down almost completely and started over.

That original implementation remains archived as v0.1.0. It was ambitious: Git refs managed repository views, a SHA-256 CAS stored artifacts, and the same system handled upstream synchronization, multi-target cloud publishing, verification, repair, garbage collection, a Cloudflare Worker, CDN purges, edge validation, and production migration.

Many of those features worked, and some paths passed acceptance tests against real APT and DNF clients and a non-production R2 environment. But the flaw was equally clear: the repository model, cloud provider, CDN, edge runtime, and migration workflow were too tightly coupled. Proving one feature correct required half of the rest of the system; every small change dragged a long acceptance matrix behind it.

In the end, I shelved it.

I did not abandon the goal, only the route to it. The worst fate for an infrastructure tool is to have a little of everything without any layer that can be explained and verified on its own. So the second version rebuilt the smallest self-contained slices first:

• P0 / Plain Create: one directory in, one working repository out;
• P1 / Managed Control Plane: Workspace, Repository, Dist, Membership, Build, Generation, Check, Changes, and Operation Log;
• More complex synchronization, remote publishing, CDN, and provider control planes went back into separate acceptance queues, one capability at a time.

v0.2.0 established today’s Plain + Managed foundation: a single package pool, metadata views, deterministic builds, locks, logs, crash recovery, Generations, and publication to filesystems and R2.

v0.3.0 introduced no new conceptual layer. Instead, it removed the old V1 runtime, tightened the cloud-transfer boundary, and fixed repeated reads, per-object queries, payload commits, and observability at large scale in both Plain and Managed modes. The current release binary depends only on the new V2 core. The old implementation remains in Git history and the v0.1.0 / v0.2.0 tags as a record of what we learned, not as a second source of truth.

This path looks slower than building everything for one grand reveal, but it is faster. Every layer has an independent contract, explicit failure semantics, and acceptance tests against real clients. The next layer rests on solid ground, not on an increasingly unreadable wish list.

Where SOW Goes Next

SOW 0.3 can create repositories, manage membership and snapshots, calculate changesets, and publish to filesystems and R2. It is still some distance from the complete software-artifact control plane I have in mind.

The roadmap has four main tracks:

1. Upstream repository synchronization. Consume upstream APT/YUM indexes directly, verify signatures and digests, fetch only missing artifacts, and bring mirror results into the same Package Object, Membership, and Generation model.
2. More complete incremental delivery. Today, changes and target checkpoints already make changesets explicit and reusable, so SOW can publish only the delta. Next comes support for more object stores and synchronization providers, with large remote inventories, resumable transfers, conditional writes, and safe-deletion evidence forming a reliable end-to-end system.
3. CDN and cache control. A CDN purge is not merely “call an API.” It must be bound to an exact Generation, cache TTL, receipt, and failure-recovery protocol. V1 proved this path can work, but it will return as an independent, testable module rather than being welded back onto the repository core.
4. Version and retention policies. Dist, Generation, retain, and target can already express beta, latest, stable, and monthly snapshots. Higher-level policy orchestration will eventually make common release cadences possible without hand-wiring them through external scripts.

Most of these capabilities existed in some form in the first version. I will not port the old code wholesale. As with 0.2 and 0.3, I will bring back one sharply bounded, independently testable capability at a time.

No more disappearing to build the grand design in one shot. Ship small, complete systems continuously.

The Pig Family Keeps Growing

SOW is part of Pigsty’s increasingly elaborate porcine universe. The naming scheme keeps getting more ridiculous—and more complete:

• Pigsty: the sty, responsible for installing and managing the PostgreSQL ecosystem;
• SOW: the mother pig, responsible for organizing, building, and publishing software repositories;
• Boar: the male pig, a graphical control plane for Pigsty now under development;
• Silo: the grain bin, responsible for S3-compatible object storage;
• Oink: the sound pigs make, powering the documentation and website framework;
• Snort: the pig rooting around, collecting logs and monitoring metrics.

The names are jokes first, of course. But behind them, a complete chain is taking shape: SOW organizes the artifacts; Silo stores them; Pigsty installs them into running systems; Snort watches those systems; and Oink explains everything. SOW fills the part of that chain that was easiest to overlook.

A software repository looks like a directory that Nginx can serve. But once it carries 100,000 objects across multiple operating systems and architectures for countless users, it is really a headless database. It has objects, relationships, versions, transactions, logs, garbage collection, and commit pointers that absolutely must be correct.

SOW makes those hidden rules explicit. It replaces the hopeful assumption that “the legacy scripts are probably fine” with an engineering contract backed by checks, recovery, and auditability. If all you want is an offline repository, start with one command:

sow create /srv/repo

If you also maintain a long-lived software distribution, visit the SOW project site or go straight to the documentation to see what lies beneath.

SOW is licensed under the Apache-2.0 license. The current v0.3.0 provides amd64 and arm64 archives for Linux and macOS, plus RPM and DEB packages for Linux. Get it from the download page, or browse the source code.

A hundred thousand packages aren’t frightening. Treating them as nothing more than a hundred thousand files is.

1.3 - Pigsty v4.4: From Integration to Distribution

Originally published on VONNG.

GitHub Release | Release Note

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.

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 copy

There 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 instance

Pig 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 restore is the low-level pgBackRest recovery primitive, responsible only for files and the recovery target.
• pig pitr is 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" -y

Recovery 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.

GitHub Release | Release Note

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_64 and aarch64 passed.
• 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/patroni and job=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.
• pig automation scripts must pass -y/--yes when running destructive commands; both pig pb restore and pig pitr require exactly one explicit recovery target. See the pig v1.5 release notes.
• Supabase Analytics now uses the _supabase database and _analytics schema; create these objects before switching an existing deployment to the new stack.

Security and Operations

• The pg-pitr wrapper 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 .env files are set to mode 0600, and Grafana no longer prints the administrator password.
• The dbsu sudo 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
• bootstrap now reuses an existing /www directory, 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, and odbc_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

Infrastructure Package Changes

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

1.4 - Instantly Clone PostgreSQL Databases—No Black Magic Required

Originally published on VONNG.

Six months ago, on January 8, 2026, I wrote Git for Data: Instant PostgreSQL Database and Instance Cloning, introducing a new feature in PostgreSQL 18 and Pigsty v4.0: instant database cloning. With filesystem copy-on-write (CoW) and PostgreSQL 18’s new file_copy_method = clone setting, you can clone a huge database in seconds without consuming additional storage.

This is a particularly good fit for AI agents. As I wrote in What Kind of Database Do AI Agents Need?, ultra-low-cost database cloning is critical for counterfactual experiments. So when Pigsty 4.0 shipped, I added this capability to its PostgreSQL database provisioning workflow.

Today I saw an article from Aliyun announcing support for this feature in Alibaba Cloud RDS for PostgreSQL. I couldn’t help laughing: that took them long enough. The feature itself is not complicated. It requires no kernel patch—just enable one setting in PostgreSQL 18 and add a STRATEGY option when creating the database. But simple as it sounds, a robust implementation still has a few edge cases to handle.

A Few Improvements

Previously, cloning a database through Pigsty’s IaC-style workflow was still somewhat cumbersome: first define the clone with another database as its template, then run the database creation workflow.

So for the Pig v1.5 release, I turned database cloning into one simple command: pig pg clone. If you have a database named meta, just run pig pg clone meta, and it automatically creates a clone.

You can, of course, customize its behavior with options—for example, by specifying the branch name. If you do not provide one, Pig generates names sequentially by appending an underscore and a number.

The command automatically detects whether instant cloning is both enabled and supported. At the moment, Pigsty on XFS satisfies those prerequisites. If so, Pig performs an instant clone. If not, it warns you, waits for confirmation, and performs a conventional clone instead. Use -y to skip the confirmation.

As long as the underlying filesystem supports CoW, such as XFS, cloning a database takes essentially constant time—usually a few hundred milliseconds—and consumes no additional space. New storage is allocated only for blocks actually dirtied by subsequent writes.

Agent-Native CLI

This command-line tool is built specifically for DBAs and DBA agents. You could already clone a database with an Ansible playbook or Pigsty’s /pg/bin/pg-clone shell script, but neither is as convenient as using the pig CLI directly.

For example, before executing an operation, you can use --plan to print the plan. It tells you what Pig will do and what risks are involved. You can also use -o json or -o yaml to return results in JSON or YAML.

Incidentally, both normal command output and help output are available as text, JSON, or YAML. That is especially useful to agents: they can explore the CLI and retrieve exactly the structured help they need. Every command in pig supports this.

I call this design an Agent-Native CLI, and I have written about it before.

Instance-Level Forks

Database cloning is not the only related new feature worth mentioning. In Git for Data: Instant PostgreSQL Database and Instance Cloning, I also covered instant instance-level cloning, which I call a “fork.”

Run pig pg fork dev, and Pig creates an instance named dev from the current instance, assigning it a new random port. This is extremely useful when recovering from an accidental deletion: first create a temporary fork without consuming additional storage, then quickly run an incremental PITR on the fork to roll back and validate the result. Once you know the recovery is correct, perform it on the main instance.

PITR with pig is now very convenient as well. The example below performs an end-to-end point-in-time recovery to a specific timestamp, making PITR about as foolproof as it gets. You can still use pig pgbackrest when you want precise control over every operation.

This release of the pig CLI adds many management features, including operations for PostgreSQL, Patroni, and pgBackRest. They are now all exposed as Agent-Native CLI commands like pg clone and pg fork, making them equally convenient for human DBAs and AI agents. I will write a dedicated article about them in a few days.

Further Reading

• Git for Data: Instant PostgreSQL Database Cloning
• Put Your AI Agent’s State in a Database
• What Kind of Database Do AI Agents Need?

1.5 - What Is a PostgreSQL Distribution?

Originally published on VONNG.

People often ask me: what exactly is Pigsty?

My usual answer is: a PostgreSQL distribution.

The next question is usually: what, then, is a “PostgreSQL distribution”?

That is a good question. And the best place to begin is not databases, but operating systems.

I. Start with Linux Distributions

When most people hear “distribution,” they think of Linux distributions: Red Hat, Debian, Ubuntu, SUSE, Arch, and so on. But if Linux already exists, why do we need Linux distributions? What exactly is the relationship between the two?

The answer is simple: Linus Torvalds only writes the kernel.

Compile the Linux kernel and you still do not have a usable machine. There is no shell, init system, C standard library, coreutils, package manager, networking toolkit, user space, or security-update policy. The kernel schedules hardware and exposes system calls, but an industrial-scale gulf separates that from “a usable operating system.”

Someone has to bridge that gulf, and there are countless ways to do it. glibc or musl? systemd or OpenRC? apt, dnf, or pacman? A release every six months, or rolling releases? What should the default security policy be? How are packages signed? How are vulnerabilities patched? How long are versions maintained? Which services are enabled by default? The accumulated answers to those questions are what make a distribution.

A distribution, then, does not merely deliver a kernel. It delivers an integrated set of decisions—and the credibility of an organization willing to stand behind those decisions over time.

Nobody says Debian, Red Hat, and Ubuntu are competing with Linus over who writes the better kernel. They compete at a different task: turning a shared kernel into a system that is more reliable, consistent, and easier to ship.

The kernel is a commons; the distribution is industrialized delivery. The real value and competition sit not in the kernel, but in the distribution layer. Nobody competes with Linus to write a “better kernel,” yet Red Hat, Debian, and Ubuntu have spent three decades competing over how best to integrate that kernel into a usable system.

That is the key to understanding PostgreSQL distributions.

II. Apply the Analogy to PostgreSQL—Carefully

PostgreSQL is often described as the Linux kernel of the database world. But if you map the Linux analogy directly onto PostgreSQL, it breaks almost immediately.

PostgreSQL is not the Linux kernel. Compile PostgreSQL from source, run initdb, and it works. The SQL engine, transactions, MVCC, WAL, replication protocol, psql, and client libraries are all there. The official PGDG repositories also ship prebuilt binaries that users can install and start directly.

The Linux kernel is not useful on its own, but the PostgreSQL kernel can run independently. That raises an obvious question: if PostgreSQL already works by itself, what problem is a PG distribution supposed to solve?

A standalone PostgreSQL instance is an excellent database kernel. A production system, however, needs more than “it starts.” If the primary fails, what takes over? Who notices when a backup is corrupt? Can you recover an accidentally deleted row to a specific point in time? How does the connection pool redirect traffic? How are certificates rotated? How are metrics collected and alerts evaluated? How are extension versions managed? How is configuration drift corrected? How do upgrades work? How is a new replica provisioned? After recovery, what closes the loop and returns the system to a healthy steady state?

Neither initdb nor yum install postgresql answers those questions.

That is where a PG distribution earns its keep. It does not turn PostgreSQL into a usable database—PostgreSQL already is one. It integrates the PostgreSQL kernel into a production-ready data service.

III. The Three Layers of a PG Distribution

A serious PG distribution has at least three jobs: selection and integration, build and distribution, and orchestration and control.

All three matter, but their marginal value is not equal. The further down the list you go, the closer you get to the real battleground.

1. Selection and Integration: Make Decisions for the User

Production PostgreSQL is not a bare postgres process. You need backups, high availability, connection pooling, monitoring, logging, alerting, object storage, extensions, an access-control model, and sensible defaults. Every category offers a long list of choices.

For backups, you might use pgBackRest, Barman, WAL-G, pg_basebackup, or a hand-rolled script built on PostgreSQL’s backup primitives. For high availability, there is Patroni, repmgr, Pacemaker, or even Pgpool-II pressed into service for primary/standby failover. Monitoring might mean Prometheus, VictoriaMetrics, Grafana, Zabbix, or any number of combinations.

This layer tests a distribution author’s judgment, experience, and sense of responsibility. Being opinionated does not mean making arbitrary choices for users. It means having learned from enough failures to know which paths are sound—and which are better.

To be fair, differentiation at this layer is narrowing. Good tools used for long enough tend to produce community consensus: Patroni is increasingly hard to avoid for HA, pgBackRest for backups, and combinations such as Prometheus and Grafana for monitoring. Selection still matters, but “I chose the right components” is no longer much of a moat by itself.

Choosing well is not enough. You also have to deliver those choices reliably.

2. Build and Distribution: A Supply Chain Is Trust, Not a Gimmick

The second layer is build and distribution. It is often underestimated because users see a package name, not the unglamorous work behind it: multiple operating systems, architectures, versions, and extensions; dependency resolution; ABI compatibility; GPG signing; CVE response; repository availability; and version lifecycle management.

PGDG already provides a formidable piece of public infrastructure. Its YUM and APT repositories deliver prebuilt PostgreSQL binaries, more than a hundred extensions, and several critical ecosystem components. It is an excellent commons.

Precisely because that commons is so good, differentiation at the build-and-distribution layer requires something more. Pigsty’s own repository, for example, fills in a large part of the missing extension catalog—another 300 extensions—along with infrastructure packages. It ships native RPM and DEB packages across 16 Linux distributions and has been maintained continuously for almost four years.

Long-term credibility in packaging, fast patching, a stable supply chain, and a sustained track record of reliable maintenance do form a barrier—and that barrier compounds over time. But this is a defensive capability. It can make users comfortable basing production systems on your repository, yet by itself it rarely explains why they must choose you.

What truly separates a distribution from an “install some packages” script is the next layer: orchestration and control.

3. Orchestration and Control: Turn Static Packages into a Living System

The hardest part of a distribution is orchestration and control. Judgment about component selection is converging, while build and distribution are largely defensive. Orchestration and control are where implementations are tested against one another in the real world. The challenge fits into one sentence: How do you turn all these static packages into a dynamically running service?

Think of a software repository as a supplier of flour, eggs, and butter. It does not bake them into a cake. Even if every package comes with a detailed recipe—that is, documentation—you are still a long way from a finished cake. And some production systems do not merely need a cake; they need an automated cake factory.

The gap between many established open-source distributions and cloud RDS offerings lies precisely in this last mile. One gives you a collection of installed packages. The other sells a ready-to-use service with automated operations and self-healing. The indispensable step between them is orchestration.

Orchestration is the act of “cooking”: turning something static, like software on a DVD, into a live, dynamic system. It must handle everything the PostgreSQL kernel leaves behind after initdb, and everything a package repository never attempts to manage: which components start in what order and what depends on what; how a failed primary is detected, a new leader elected, traffic redirected, pooler connections reestablished, and a replacement replica provisioned—the entire closed loop of failure recovery; and, most importantly, how the whole system remains at its declared desired state and automatically corrects any drift.

Orchestration and control form a moat precisely because there is no commons at this layer. Nobody turns the flour and eggs into a cake for you. Every distribution has to do that work itself, and the difference in results is immediately obvious.

IV. Two Paths to Orchestration: Kubernetes-Native and Linux-Native

Once orchestration becomes the central problem, the question is: at what layer should the control plane live?

There are two mainstream answers, and they define the two principal tracks for PG distributions today. The essential distinction is where orchestration and control are implemented: one path builds on Kubernetes as a common substrate; the other returns to the Linux operating system and builds upward from there. Neither is universally better. They make different tradeoffs.

Path One: Kubernetes-Native

This path treats the database as a first-class citizen on Kubernetes and uses the Operator pattern for orchestration. You submit a declarative custom resource defined by a CRD, and the Operator’s reconciliation loop continuously drives actual cluster state toward the desired state. Provisioning, monitoring, failover, and scaling all happen at the Kubernetes layer.

This is currently the busiest and most crowded track. Its players include CloudNativePG, led by EDB, with roughly 8,900 stars and currently the leading PG Operator; the Zalando Postgres Operator, with about 5,200; Crunchy PGO, with about 4,400; KubeBlocks, with about 3,100; and a longer list including StackGres, Kubegres, Tembo, KubeDB, and the Percona Operator.

The advantages are clear: a unified control plane, a declarative API, smooth GitOps integration, and an easy interface for platform teams. For organizations that already treat Kubernetes as their operating system, putting databases on Kubernetes is a natural extension.

The cost is equally clear. You are not merely adding a PG Operator. You are adopting the entire Kubernetes control plane, storage and network abstractions, scheduling model, authorization model, failure model, and cognitive load. The real entry cost is not the Operator itself, but whether your organization has already paid the Kubernetes tuition.

Path Two: Linux-Native

This path does not put the database inside Kubernetes. It returns to the operating system: run directly on Linux, on physical or virtual machines; install RPM or DEB packages; manage services with systemd; and drive administration with Ansible or a similar infrastructure-as-code tool.

There are fewer open-source players on this track: Pigsty, with roughly 5,200 stars; Autobase, with about 4,300; pgEdge, with about 700; and EDB TPA, with about 90. Alongside them is a full roster of commercial distributions without public star counts but with substantial enterprise weight: EDB Postgres Advanced Server—EDB’s flagship and arguably the Red Hat of the PostgreSQL world—Percona Distribution, CYBERTEC PGEE, ClusterControl, and others.

The advantages are a shorter path, fewer dependencies, and closer proximity to the database itself. There is no extra abstraction layer, the failure domain is smaller, behavior is more predictable, and DBAs can understand and take over the system directly. The cost is that Kubernetes is no longer providing desired-state reconciliation, idempotent execution, failure recovery, or upgrade orchestration. You have to implement those capabilities yourself while also confronting the differences across more than a dozen major versions of mainstream Linux distributions. It is continuous, unglamorous work.

Pigsty’s Choice

Both paths are reasonable. The right one depends on where your team already stands and where it makes sense to place the complexity. Pigsty chose the Linux-native path. I have explained the reasoning at length in Should Databases Be Deployed in Kubernetes? and Is Containerizing Databases a Good Idea?. My view is that this path better fits the nature of databases. It is difficult, but correct.

And on that difficult path, Pigsty has moved to the front of the pack. Measured by GitHub stars, it is now the leading Linux-native project, with 5,200 versus roughly 4,300 for Autobase. Across the entire PostgreSQL distribution landscape, including Kubernetes-native projects, it ranks second only to EDB’s CloudNativePG.

Ask a mainstream AI model today, “How should I self-host an enterprise-grade PostgreSQL service on Linux?” and Pigsty is generally its first recommendation. For a project led by an independent developer and unaffiliated with any cloud vendor, reaching that point has not been easy.

V. One Step Further: A Meta-Distribution

The story could end there. But Pigsty does something else that pushes at the boundary of the term “PG distribution.”

The industry usually assumes that a distribution is built around one fixed kernel. Debian and Red Hat are built around Linux. Traditional PG distributions are built around the vanilla PostgreSQL kernel. A distribution and its kernel are almost inseparable.

The PostgreSQL world, however, contains some unusual variants. OrioleDB replaces the storage engine. Babelfish adds SQL Server protocol compatibility. PolarDB for PostgreSQL implements a RAC-style architecture. IvorySQL supports Oracle syntax. openHalo is MySQL-compatible, while Percona TDE adds transparent encryption. These projects modify the PG kernel. Strictly speaking, they are no longer “pure PostgreSQL,” but distinct species and subspecies within the PG-compatible family. Traditionally, every variant would need to build its own operational stack.

Pigsty takes another approach: extract the orchestration and control foundation, and make the kernel itself a replaceable layer. This is the natural consequence of taking the third layer far enough. Once the control plane is sufficiently flexible and no longer hard-wired to a specific kernel, replacing that kernel becomes a matter of swapping a build artifact and a configuration template. We build binary packages and provide configuration templates for these different PG forks, allowing users to run different kernels on the same foundation. Pigsty currently supports more than 12 kernels.

In that sense, Pigsty is no longer merely a “PostgreSQL distribution.” You can use it to derive a distribution of your own: an IvorySQL distribution, a PolarDB distribution, or a TDE distribution. By combining modules, you can even turn it into a distribution for Redis, Etcd, or MinIO; for Prometheus or VictoriaMetrics; or even for Claude Code and Codex.

More precisely, it is a meta-distribution: a distribution for building distributions. A foundation that can be repeatedly tailored, reused, and redistributed is itself a transferable capability. It no longer belongs to one kernel, or to one person.

./configure                     # Use the meta.yml configuration template by default
./configure -c meta             # Explicitly use the single-node meta.yml template
./configure -c rich             # Use the full-featured template with all extensions and MinIO
./configure -c slim             # Use the minimal single-node template with only a PG HA cluster

# Use different database kernels
./configure -c pgsql            # Vanilla PostgreSQL, with 531 optional extensions (14–18)
./configure -c mssql            # Babelfish kernel, compatible with the SQL Server protocol (17)
./configure -c polar            # PolarDB PG kernel, Aurora/RAC-style (17)
./configure -c ivory            # IvorySQL kernel, compatible with Oracle syntax (18)
./configure -c mysql            # openHalo kernel, compatible with MySQL (14)
./configure -c pgtde            # Percona PostgreSQL Server with transparent encryption (18)
./configure -c oriole           # OrioleDB kernel with OLTP enhancements (16–18)
./configure -c agens            # AgensGraph graph-database kernel (16)
./configure -c pgedge           # pgEdge distributed-database kernel (18)
./configure -c ha/citus         # Distributed, highly available PostgreSQL with Citus (14–18)
./configure -c supabase         # Self-hosted Supabase configuration (15–18)

# Use multi-node high-availability templates
./configure -c ha/dual          # Use the two-node HA template
./configure -c ha/trio          # Use the three-node HA template
./configure -c ha/full          # Use the four-node HA template
./configure -c infra            # Install only monitoring infrastructure and Nginx, for observability and web hosting
./configure -c vibe             # Configure a Claude/Codex + PGFS/Code development environment

Epilogue: A Distribution Is a Supply Chain of Trust

Return to the original question: what is a PostgreSQL distribution?

At the technical level, it has three core jobs. Selection and integration make the right decisions on your behalf. Build and distribution deliver the artifacts created by those decisions. Orchestration and control turn those static packages into a living, self-healing system.

But the real soul of a distribution lies beneath those three technical layers.

Technology can be copied. Component choices can be imitated, packages can be rebuilt, and anyone willing to invest enough time can reproduce 70 or 80 percent of the orchestration. Two things cannot be copied—and determine whether a distribution can be trusted for the long term: a community that continues to use and maintain it, and the trust that grows from that work over time.

Users do not merely need an answer to “Which package should I install?” They need answers to harder questions. Whose packages do I trust? Whose defaults? Whose extension builds? Whose HA decisions and backup-recovery process? Who patches a CVE promptly? Who will still maintain this path five years from now? When configuration drifts, a failover occurs, a version is upgraded, or data must be restored—at the moments that matter most—who can bring the entire system back under control?

The answers point not to a piece of code, but to the person and community that continue to take responsibility for it. The essence of a distribution is to gather responsibilities scattered across source code, builds, signatures, repositories, extensions, configuration, orchestration, monitoring, upgrades, and disaster recovery into a supply chain of trust that can be verified, reproduced, audited, and relied upon over the long term. Trust accumulates as promises made along that chain are honored again and again. It cannot be bought or copied. Only a community can grow it over time.

Cloud services provide trust too, but they hide the chain inside a black box. You buy managed trust, while surrendering transparency, portability, and ultimate control. You trust the cloud vendor to choose the right components, apply patches, maintain backups, handle failures, and plan upgrades. You also trust it not to box you in on pricing, access, ecosystem control, compliance, or availability. That is still trust. Its price is that you can no longer inspect or take over the chain yourself.

Pigsty takes another path. It does not mystify complexity or outsource responsibility to an invisible control plane. It makes the chain visible, codifies it, signs it, orchestrates it, and returns as much control as possible to the user. Pigsty is therefore not a “tool for installing PostgreSQL,” nor merely a “script for building your own RDS.” It aims to deliver an open PostgreSQL supply chain of trust: from the upstream kernel to extension artifacts, from RPM and DEB repositories to HA orchestration, from monitoring and alerting to backup and recovery, and from a single PG kernel to the entire family of PG-compatible kernels. Every link can be verified, and every link can be brought under the user’s control. Behind it stands a community willing to maintain it for the long term.

What Linux distributions ultimately accumulated was never just the technical ability to integrate a kernel into a system. It was the credibility earned by names such as Debian and Red Hat through decades of simply continuing to be there. Pigsty aims to grow that same kind of trust in the PostgreSQL world—and to keep it open, auditable, and under the user’s control.

A real distribution ultimately delivers not software, but a supply chain of trust that can be audited, reproduced, migrated, and relied upon for the long term—together with a community willing to stand behind it.

No rented cloud. No vendor worship. No putting complexity—or trust—inside anyone else’s black box.

Instead, put the ability to run a first-rate production database service back in the hands of users willing to run it themselves—along with a community willing to support it for the long haul.

1.6 - Pigsty v4.3: 510 Extensions & Ubuntu 26

Originally published on VONNG.

Pigsty v4.3 is out. If v4.2 was about “twelve kernels”, v4.3 is about extension density.

This release takes the supported PostgreSQL extension count from 460 to 510, a new high-water mark for Pigsty. Ubuntu 26.04 enters the support matrix, while Ubuntu 20.04 formally retires. Core components such as Supabase, pgEdge, PolarDB, Grafana, and MinIO also get a broad refresh.

GitHub Release | Release Note

Pigsty v4.3 Goes Mainstream

On GitHub, 5,000 stars is a useful line in the sand. It is where an open-source project starts to look “mainstream” rather than merely interesting. The most practical perk is surprisingly mundane: you become eligible for free ChatGPT / Claude subscriptions.

Pigsty recently crossed that line: it now has 5,066 stars. There are 11,621 GitHub repositories with more stars than that, which puts Pigsty roughly around the top 10,000 repos, or the top 0.005% of GitHub projects. For a database distribution, that number carries more weight than it would in many trendier categories. By GitHub stars, Pigsty is now the No.3 PostgreSQL distribution overall, and the No.1 Linux-native PostgreSQL distribution.

What surprised me more was the traffic to Pigsty.io. In March, monthly unique visitors were still below 20 million. By the end of April, they had crossed 100 million. More than 99% of that traffic comes from AI systems and agents. That means Pigsty’s documentation has become part of the working corpus for mainstream AI systems, and a piece of infrastructure used by AI agents. For what is still, at its core, a personal project, that is a fairly rare place to be.

510 Extensions

PostgreSQL’s strongest feature is extensibility. The engineering reality behind that ecosystem is less glamorous. Pigsty v4.3 adds about 50 PostgreSQL extensions and brings the total available count to 510. The new additions cover a wide range:

• block_copy_command, external_file, logical_ddl, and pg_query_rewrite: lower-level tools around DDL and execution behavior.
• datasketches, onesparse, rdkit, pghydro, and provsql: data science, sparse computation, cheminformatics, hydrology, and probabilistic database extensions.
• pg_text_semver, pg_variables, pg_when, pgcalendar, and pglock: everyday development and administration tools.
• postgresbson, pgproto, re2, pgmq, and pgmqtt: protocol, queueing, regex, and messaging components.
• storage_engine, pg_pathcheck, pg_savior, and pg_textsearch: more advanced extensions that deserve closer attention to loading mode and risk boundaries.

Many of these extensions have already gone through the pgrx transition, from 0.16.1 to 0.17.0. Some, such as pg_search and pg_trickle, are already on the pgrx 0.18.0 line. The Rust extension ecosystem is getting more active, which is a good thing. For a distribution maintainer, it also means every build cycle has to deal with the Rust toolchain, cargo dependencies, PostgreSQL version compatibility, and platform differences.

Users see one line of SQL: CREATE EXTENSION. The maintainer sees a matrix and one or two hundred packages. The good news is that my extension maintenance workflow is now wired into an Agent-based pipeline. Whether it is adding a new extension or updating an existing one, the process is automated enough that the extension count can keep going up while the maintenance burden stays within what one person can handle.

Ubuntu 26.04 Joins the Matrix

Pigsty v4.3 adds Ubuntu 26.04 x86_64 / arm64 support, and formally deprecates Ubuntu 20.04.

Pigsty now supports 8 major OS versions across both x86_64 and arm64, for a total of 16 platform combinations:

Ubuntu 24.04, noble, is still the most widely used baseline today. Ubuntu 26.04 will likely replace it gradually over the next few years.

We added preliminary Ubuntu 26.04 support on the day it was released, but Pigsty ships many third-party extensions, and those need time to build and verify. For Ubuntu 26.04, the regular extensions and offline bundles are now ready. Rust extensions are not provided yet, but they will be filled in later.

Ubuntu 24.04 has also been refreshed from 24.04.3 to 24.04.4, and Debian 13 from 13.3 to 13.4.

Pigsty’s Vagrant and Terraform templates have been updated accordingly. Alibaba Cloud does not yet provide Ubuntu 26.04 images, so that part will have to wait.

Kernel Updates: Supabase, pgEdge, PolarDB

Supabase self-hosting templates are updated to the latest version. Pigsty is one of the few open-source PostgreSQL distributions that provides an enterprise-grade self-hosted Supabase option. This release refreshes the Supabase template, and also adds self-hosting support for Insforge, a lighter “Supabase-like” stack.

pgEdge moves to PG 18. The core value of pgEdge is multi-master replication on PostgreSQL, built on Spock and two other extensions. Spock’s newest supported PostgreSQL major version has moved from 17 to 18, so Pigsty rebuilt the stack accordingly.

PolarDB moves to PG 17, with the package version now at 17.9.1.0. PolarDB is a shared-storage PostgreSQL kernel fork. Its previous baseline was PG 15; this release jumps it to PG 17.

OrioleDB keeps moving as well, with OriolePG 17.18 and OrioleDB beta15 / 1.7. OrioleDB is still evolving quickly. I would not rush it into production, but as a frontier project in PostgreSQL storage engines, it is worth trying.

Cloudberry is updated to 2.1.0, and Pigsty now adds cloudberry-backup and cloudberry-pxf packages. v4.2 brought Cloudberry back into the distribution matrix; v4.3 fills in the surrounding tools.

Grafana 13 and Victoria Refresh

Observability is part of Pigsty’s foundation, and this release updates a good chunk of that stack. The biggest visible change is Grafana 13. The jump from 12 to 13 brings a number of new features, including Dashboard Tabs, which opens up some interesting layout options.

Pigsty v4.3 updates Grafana to 13.0.1 and refreshes the related plugin packages:

• grafana: 12.4.1 -> 13.0.1
• grafana-plugins: 12.3.0 -> 13.0.0
• grafana-infinity-ds: 3.7.4 -> 3.8.0
• grafana-victoriametrics-ds: 0.23.1 -> 0.24.0

The Victoria stack also gets a batch update:

• victoria-metrics: 1.138.0 -> 1.142.0
• victoria-metrics-cluster: 1.138.0 -> 1.142.0
• vmutils: 1.138.0 -> 1.142.0
• victoria-logs: 1.48.0 -> 1.50.0
• vlagent / vlogscli: 1.48.0 -> 1.50.0
• victoria-traces: 0.8.0 -> 0.8.2

There is also a small user-reported fix: the VictoriaTraces Grafana datasource path is now corrected to /select/jaeger.

etcd CVE Fix

etcd 3.6.8 recently had a CVE. 3.6.9 fixed it, but also introduced a new problem: it added auth to the member list API, which broke Patroni, the PostgreSQL HA component, before Patroni 4.1.1. Patroni 4.1.1 fixed that compatibility issue.

The important thing for users is version pairing: Patroni <= 4.1.0 should be used with etcd <= 3.6.8, while Patroni >= 4.1.1 should be used with etcd >= 3.6.9. Old with old, new with new. Mixing the two sides causes trouble.

In v4.2.2, the EL side had already moved to etcd 3.6.10 and Patroni 4.1.1. The DEB side lagged behind because the APT repo updated more slowly, so it still used etcd 3.6.8 and Patroni 4.1.0. In v4.3, the DEB side is now updated too, so users can upgrade without worrying about that mismatch.

MinIO CVE Fix

I forked MinIO earlier, fixed several CVEs in April, and wrote about the background in Keeping MinIO Alive, Promise Kept. Read that post if you want the details. Pigsty v4.3 ships the fixed build: 20260417000000.

The fixes cover OIDC/JWT, LDAP STS login, replication headers, S3 Select, unsigned-trailer signature verification, and a few adjacent paths. For Pigsty users, the important part is not the exploit mechanics. The important part is that the object storage package has moved to a fixed version, and the offline bundles have been refreshed too.

The fork, Silo, is now used in real production deployments, including Grafana Loki. The Silo docs site sees tens of millions of requests per month, and Docker Hub downloads have passed 100k. It is probably the most widely used MinIO fork at this point. I am happy about that, but to be clear, this is not my main job. I just want Pigsty users to have a usable open-source object storage option.

Recently I also talked to RustFS team. After talking with the team, I learned that they plan to make RustFS a drop-in replacement for MinIO. If they can really pull that off, I will seriously consider replacing MinIO with RustFS in Pigsty. This release packages RustFS’s first Beta after it left Alpha. A GA release is planned around July.

Vagrant Templates Move to cloud-image

For many people, Vagrant is just a local testing tool. For Pigsty, which needs to verify multiple operating systems, architectures, and topologies, it is an important development and acceptance-test entry point.

Pigsty v4.3 moves all Vagrant templates to the cloud-image series. The reason is simple: this is the only image family that covers every Pigsty-supported OS across all four combinations of VirtualBox/Libvirt and amd64/arm64.

The change reduces uncertainty from OS image differences. Traditional Vagrant boxes vary a lot in quality. Network behavior, disk layout, cloud-init, and guest tools can all differ in subtle ways. cloud-image is the more standard, distribution-maintained path. Once everything is on that track, adaptation and debugging become much easier.

One caveat: the default network interface name is no longer eth1. If you need to test VIP-related features, remember to adjust the interface name in your config.

Small Fixes Worth Calling Out

v4.3 also includes a few smaller fixes that came from real user pain.

Relaxed PostgreSQL username validation: Pigsty now allows @.- in usernames. In real enterprise identity systems, email-style usernames and domain-tagged usernames are common. A database distribution should not block valid use cases with an overly narrow regex.

IPv6 nameserver parsing fix: The old logic only extracted IPv4 DNS servers, which missed IPv6 nameservers. That is fixed now. IPv6 support is often not the main path, but when an environment has it, it is not optional.

Other Additions

Pigsty v4.3 also adds experimental self-hosting templates for Hindsight, a memory framework based on PostgreSQL and pgvector, and Hermes Agent. They are still pilot features, so I will not spend much time on them here.

Closing Notes

Pigsty v4.3 is not a huge release in the sense of sweeping framework or interface changes. It is also not small: shipping 50 new extensions in one go is real work.

There is no single headline feature here. Instead, the release moves many things users actually care about: more extensions, newer operating systems, updated kernel forks, a fresher monitoring stack, more stable Vagrant templates, fixed CVEs in the object storage package, and a few paper-cut fixes people actually hit.

That is often where the value of a database distribution lives: the unsexy parts. You do not have to track the build status of 50 extensions yourself. You do not have to audit the Ubuntu 26.04 package matrix yourself. You do not have to maintain a MinIO CVE fork yourself. You do not have to sort out Grafana 13 plugins, Victoria component versions, or which Vagrant images to trust.

Pigsty rolls all of that into a release. You just use it. The complete v4.3.0 release notes and package change summary follow.

v4.3.0

Highlights

• Added about 50 PostgreSQL extensions, bringing the total available extension count to 510.
• Added Ubuntu 26.04 x86_64/arm64 support, deprecated Ubuntu 20.04 support, and refreshed minor OS variants to Debian 13.4 / Ubuntu 24.04.4.
• Kernel updates: Supabase is updated to the latest version, pgEdge to PG 18, and PolarDB to PG 17.
• Grafana is updated to 13.0.1, and MinIO now uses the pgsty/Silo branch with CVE fixes.
• Vagrant templates now consistently use cloud-image series images.

Bug Fixes

• Relaxed PostgreSQL username validation to allow @.- in usernames.
• Fixed IPv6 nameserver parsing so DNS configuration is not limited to legacy IPv4 DNS server extraction.
• Changed the VictoriaTraces Grafana datasource path to /select/jaeger.
• Made Vagrant disk probing more robust and added bin/el-fix, a guest-network fix script for EL Vagrant images.

PostgreSQL and Extension Package Changes

Infrastructure Package Updates

Checksums

58a914fce7bc521b65e167f66e7961a3  pigsty-v4.3.0.tgz
9ce070efb0420057a83c632b2856d1b3  pigsty-pkg-v4.3.0.d12.aarch64.tgz
bf21c36d3aff94a1a6353130597ffa85  pigsty-pkg-v4.3.0.d12.x86_64.tgz
81b4790c4e5567cee9d1beadd06e48e6  pigsty-pkg-v4.3.0.d13.aarch64.tgz
06baab9341ab683eaeea2e066b28a0f4  pigsty-pkg-v4.3.0.d13.x86_64.tgz
fb4bf751df5e09f547c49b8ab7cac9a0  pigsty-pkg-v4.3.0.el10.aarch64.tgz
a3e752c8148122d1eaea74a6d8d8df0d  pigsty-pkg-v4.3.0.el10.x86_64.tgz
cb2a9af36615513e66fd5ac3e9f4d797  pigsty-pkg-v4.3.0.el9.aarch64.tgz
e24641a879dec7a8eea74dab42f85920  pigsty-pkg-v4.3.0.el9.x86_64.tgz
6b675fd8d9e039193481f0838aa4b92c  pigsty-pkg-v4.3.0.u22.aarch64.tgz
c0e344ccb9d190a619591e5d46116424  pigsty-pkg-v4.3.0.u22.x86_64.tgz
3e0ec9534cf595201ec79eb1fc6549d8  pigsty-pkg-v4.3.0.u24.aarch64.tgz
0a3d19513eca9615bdd66a4b2bf66f1d  pigsty-pkg-v4.3.0.u24.x86_64.tgz
683a10ff8fd993358d6befa9f4e02913  pigsty-pkg-v4.3.0.u26.aarch64.tgz
fd1ea5cd5554bfe91fadd51ad80860e3  pigsty-pkg-v4.3.0.u26.x86_64.tgz

1.7 - Give DBA Agents a Body

Originally published on VONNG.

HOW 2026 keynote: Give DBA Agents a Body

Part I: Opening—An Absurd Phenomenon

1. Cover

Hello, everyone. I’m Ruohang Feng, the organizer of this tools track. This is a PostgreSQL tools session, but today I don’t want to talk about how many new features some command-line utility has gained. I want to ask a more fundamental question: Why are agents that can actually manage production databases still so rare? My answer is simple: today’s models are already smart enough. What they lack is not a brain, but a body. They need to see system state, take action, judge risk, leave evidence, and back out after something goes wrong. Today I want to discuss how we can build that body for a DBA Agent.

2. An Absurd Phenomenon

Many of you probably know Pigsty. Pigsty is an open-source PostgreSQL distribution I built around a simple goal: even without a DBA or RDS, you should be able to run production-grade PostgreSQL yourself and obtain enterprise database capabilities through free, open-source software.

The project now has more than 5,000 stars on GitHub. It ranks among the leading PostgreSQL distributions and is one of the more prominent open-source projects in China’s PostgreSQL ecosystem.

How many requests do you think a site for a project like this gets each month? A hundred thousand? A million? Ten million?

3. Anomalous Traffic

None of those. The number startled me too: 90 million requests over the past month, and still climbing. At the current growth rate, it will soon approach 100 million. The obvious question is: where could that many human visitors possibly come from?

I checked the analytics. Monthly human unique visitors numbered only in the tens of thousands, with page views in the hundreds of thousands. So where did the other nearly 100 million requests come from? Judging by User-Agent strings, access paths, and trigger patterns, much of the traffic no longer came from humans browsing in the traditional sense. AI tools were reading the documentation.

4. Who Is Visiting?

After thinking about it, I realized what had happened. When we released Pigsty 4.0 early this year, we added a feature called DBA Agent. The name sounds grand, but in practice it is just a CLAUDE.md file containing two very plain rules: first, do not drop the database; second, if something goes wrong, read the documentation. Then it lists all the documentation links. That’s it.

Yet a new kind of user gradually appeared in our community. These users do not necessarily know PostgreSQL or Linux, but they do have Claude Code or Codex.

They sit at a Linux shell and tell the AI: “Install Postgres for me.” “Add a user.” “Figure out what’s wrong here.” To do that work, the AI has to keep reading the documentation. So those nearly 100 million requests were not people clicking around by hand. They were agents reading on their users’ behalf. Those agents are already playing the role of DBA—and doing a surprisingly decent job.

5. Agents Are Already Doing DBA Work

Honestly, I think these agents are doing pretty well. I use them this way myself when I run into difficult problems. In a simulated Pigsty environment, I tell an agent: I have this issue, or a customer has this issue; inspect the source code, configuration, logs, and documentation, then analyze the likely causes. Sometimes I give it a few hunches—A, B, and C—and ask which is most plausible.

More often than not, its analysis lands close to the truth. It is not always right, but it is already good enough to be impressive. So when I talk about DBA Agents today, I am not pitching a concept that exists only in a slide deck. I am describing something already happening among the users of a real open-source project.

6. D-Bot Already Proved the Point

More interesting still, while everyone is now piling into the DBA Agent space, someone already built one on Pigsty two years ago.

A team led by Xuanhe Zhou at Tsinghua University built a DBA Agent called D-Bot on a Pigsty environment, and the paper was later published at VLDB. They were still using GPT-4. Even with the models available at the time, D-Bot could diagnose fairly complex failures in Pigsty and produce evidence-backed root-cause analyses and remediation recommendations.

One major reason they chose Pigsty was that it offered an open, standardized, production-grade runtime. They could focus on the intelligence instead of rebuilding the infrastructure from scratch: monitoring data was already available, and established command-line primitives could perform the necessary operations. Two years later, model capabilities have improved many times over. What can we build today by pairing this Runtime with state-of-the-art models? I leave that possibility to everyone in this room.

Part II: Theory—What Is a Body Made Of?

7. Why Haven’t Self-Driving Databases Taken Off?

At this point someone will inevitably ask, “So is AI going to replace DBAs?” My answer is: not yet. After all, AI cannot take the blame for you. But it does reveal a real possibility: self-driving databases. The idea is not new. Oracle has talked about it, cloud vendors have talked about it, and academia has talked about it.

Yet after all these years, very few implementations are actually good. I believe the technology is finally ready. We may not be able to achieve Level 5 autonomy today, but a copilot that assists the driver is clearly within reach. The real question is: what must we provide before a database can drive itself?

8. The Database Needs Pyramid

I once drew a pyramid of database needs. At the top sits intelligence—the self-driving database, the Holy Grail. But it rests on control and insight: you must be able to see and control the system. Beneath those are the fundamentals of quality, security, efficiency, and cost. If your monitoring is incomplete, your changes still depend on inherited shell scripts, and you cannot reliably rehearse high availability or point-in-time recovery, you have no business talking about self-driving databases.

It is like trying to build a self-driving car without sensors, brakes, a steering wheel, or airbags. What good is a brilliant algorithm then? The core of a DBA Agent is therefore not the model or the agent framework. It is a deterministic environment and a body through which the agent can interact with that environment. That is the theme of this talk.

9. The Body’s Two Foundations: Eyes and Limbs

What does it mean to give an agent a body? I think the two most basic components are eyes and limbs. First, the eyes: observability. It must be able to see the database, operating system, network, disks, connection pools, backups, replication lag, and historical trends. Second, the limbs: controllability. It needs reliable ways to take action—to apply changes, restart services, fail over, back up, restore, add users, and scale up or down. Let’s start with the eyes.

10. Eyes: Observability

The first problem any DBA Agent must solve is information gathering. It needs to know what is happening now. Pigsty addressed this long ago: it provides a complete open-source observability stack built on VictoriaMetrics and Grafana, collecting nearly every useful PostgreSQL signal. For agents and humans alike, effective management begins with enough information.

AI DBA products usually begin with monitoring: metric collection, anomaly detection, and alerting, followed by a conversational interface to the agent. pgEdge’s AI DBA Workbench is a typical example. Monitoring is clearly the most basic and important component of a DBA Agent. But I have discussed it several times already and will not repeat myself today. I want to talk about the other part of the body: the limbs. Today is not about the eyes. It is about the hands and feet.

11. Four Stages of Database Automation

From an automation perspective, database management has passed through roughly four stages. Stage one is completely manual: the DBA types every command. Stage two is a pile of hand-me-down scripts or clicking around in a console—ClickOps. Stage three is infrastructure as code: declarative management with tools such as Ansible, Terraform, and Operators. Stage four is the agent: instead of writing commands one by one, the human states a goal, and the agent observes, plans, executes, and verifies.

There is a crucial dependency here. Before an agent can enter stage four, stage three must already exist. Without IaC, an agent will struggle to operate reliably. I will return to that point later. First, let us answer a more concrete question: how exactly should an agent operate a database?

12. Experts and Agents Both Need Action Interfaces

Should an agent operate a database by opening a browser and clicking around a console? Should it call an API? Or should it use the command line?

For both experts and agents, what matters is not a GUI but a clear, composable, auditable, and reproducible action interface. A CLI is one of the most natural forms, especially when it also supports structured output such as JSON and YAML. That makes it equally useful to humans and agents.

So here is one prediction: the agent era will revive the value of the CLI. In a sense, this returns us to the original Unix philosophy—everything is text, and everything composes.

13. PostgreSQL’s Problem: A Fragmented Toolchain

But there is an awkward reality: the PostgreSQL ecosystem is powerful and fragmented. You might install Postgres with apt or dnf; start it with systemctl or pg_ctl; run SQL with psql; manage high availability with patronictl; back up with pgBackRest; pool connections with PgBouncer; and handle extensions with yet another assortment of packages and configuration files.

That is fine for veterans. They know how to use each tool and where the traps are. But it becomes a problem when an agent manages the database. The agent needs one coherent action interface; it should not have to guess among scattered tools and ancient scripts every time. So we wondered whether we could build something that unified them.

14. Pig CLI Began as an Extension Package Manager

Our tool is called Pig CLI. It began as something very simple: a small Go program I wrote to solve PostgreSQL and extension installation. It does not try to reinvent apt or dnf; it adds a layer of PostgreSQL semantics on top of them. Why? Traditional package managers understand packages, not PostgreSQL extensions. If you ask to install vector, the package manager does not know which package you mean, which PostgreSQL major version, which Linux distribution, or which architecture. Pig’s first job was to translate a “package” into a “database capability.”

15. Do Not Underestimate Installation

Do not underestimate installation. For many PostgreSQL beginners, installing an extension is the first major obstacle. They want to use one, but cannot compile, package, build, and distribute it themselves, so they need a ready-made binary. What if none exists? What if the network is unreliable? What if the versions do not match? None of this is especially hard for a veteran, but it can stop a newcomer cold.

One of Pigsty’s most important jobs is maintaining binary distribution for PostgreSQL extensions. It integrates a large collection of third-party extensions and makes them work out of the box on mainstream Linux distributions. That puts many of PostgreSQL’s “superpowers” in the hands of ordinary users.

16. But a DBA Does More Than Install Software

Of course, if Pig could only install extensions, it would still be too limited. Most DBA work consists of Day 2 operations. After installation, you must create the cluster, initialize directories, configure permissions, tune parameters, create users and databases, configure connection pools, backups, and monitoring—and later perform failovers, scale out, scale in, recoveries, health checks, cleanup, repacking, and upgrades.

Pigsty historically performed most of these tasks through Ansible Playbooks. Claude Code can read the documentation and run the Playbooks, but the experience is not good enough. What we really want is to gather the primitives of daily database administration behind a single command-line interface—to evolve Pig CLI from an extension package manager into a tool that can manage the full state of a PostgreSQL system.

17. Pig CLI’s Ambition: The Swiss Army Knife of PostgreSQL

Pig CLI’s long-term goal is therefore much larger than package management. It should become the Swiss Army knife of the PostgreSQL ecosystem: install PostgreSQL, install and build extensions, initialize clusters, manage services, inspect state, manage high availability, configure backups, and perform maintenance. Can all these actions converge on a single interface?

That would free DBAs from a great deal of manual work. More importantly, it would give agents hands and feet. Humans can remember a pile of complicated tools, and agents can too, but there is no reason to make them. Give an agent a clearer, more stable action interface and it will work better.

18. An Agent-Native CLI

This raises another question. The Unix philosophy teaches KISS: make each tool do one thing well, then compose tools through pipes. If we pack all these capabilities into Pig CLI, does it become a bloated kitchen-sink application? We should answer that directly. Humans value tools that are small and elegant. For agents, self-description matters more.

An agent-native CLI must be able to explain itself. Its help text must be clear, its output structured, and its errors explicit. Humans read colored text; agents read JSON and YAML. The tool needs to serve both.

Put bluntly, the ideal is not to write a pile of Skills documents in advance to teach the agent how to use a tool. The tool itself should be sufficiently self-describing. An agent should be able to type --help and explore layer by layer: what commands exist, what parameters they take, what each parameter means, what output formats are available, and what error codes can occur.

This may sound like a detail, but it is central to CLI design in the agent era. A truly agent-native interface also needs dry runs, idempotency, explicit exit codes, machine-readable errors, permission boundaries, confirmation for dangerous operations, audit logs, and rollback suggestions. I will not go further into those details today.

19. Why Start with a Native Linux Runtime?

Some people ask why we are building command-line tools to manage Postgres directly on Linux instead of basing the system on Kubernetes. A Kubernetes Operator is certainly another kind of Runtime, but it hides many low-level details while adding another layer of abstraction and complexity. Encapsulation is good for application developers. It is not always good for a DBA Agent, because once a problem cuts through the abstraction, the agent needs to see systemd, disks, filesystems, networks, and PostgreSQL itself.

In other words, if you want to push a database runtime to its limits, controlling a connection string is not enough. Controlling one abstract API layer is not enough. You must control the environment in which the database actually runs. We are not trying to build a DBA Agent that can merely invoke tools. We want one that can see, understand, and operate the whole system. It needs more than hands and feet. It needs a complete body.

Part III: The Turn—Tools Are Not Enough; the Runtime Is the Moat

20. A Cautionary Example: OtterTune

OtterTune offers a case worth studying. Co-founded by CMU database professor Andy Pavlo, it raised a $12 million Series A to provide automatic parameter tuning for PostgreSQL and MySQL, but it never became the standard answer for self-driving databases. Why?

Its product proposition was: give us a database connection string, and we will tune the database. That sounds appealing. But a connection string is the lowest common denominator across every PostgreSQL service. What can you do with one? Run some SQL and inspect a few system views. You cannot see complete historical trends, restart the database, or change parameters that require a restart. When something goes wrong, you cannot trace the problem across layers. Is it the application, the database, the OS, or the network? You cannot see any of them.

21. No Runtime, No Expert DBA

The lesson I draw from OtterTune is this: with only a connection string and no Runtime, it is difficult to build an expert-level DBA Agent. A connection string is a narrow peephole through which you can see only one corner of a house. The important details are hidden in the operating system, disks, filesystem, service manager, monitoring history, and backup chain. No matter how smart a tool is, if it sees the world through a peephole, it can never make expert judgments.

Pigsty began as a monitoring system. Why did it later become an all-in-one PostgreSQL distribution? Because I eventually realized that to push monitoring to its limits, you must take direct control of the entire infrastructure. Otherwise, you cannot control how users deploy their databases. All you have is a connection string, and what you can do with it is extremely limited.

The key to building a DBA Agent is therefore not how polished the command-line tool looks. It is the Runtime behind that tool.

22. The Runtime Is the Real Moat

Many people building agents today like to talk about prompts, Skills, and workflows. Those are useful, of course, but let me be direct: they do not create a very strong moat. Write a veteran DBA’s experience into Markdown and model vendors can ingest it, competitors can learn it, and the next model generation may absorb much of that knowledge directly.

So what is the real moat? The agent’s understanding of your private environment. How is it deployed? What instances exist? What is the backup policy? Which alerts have fired in the past? Which operations have been performed? Which traps have people already fallen into? None of that appears in general training data.

In one sentence: a generic agent alone does not have a deep moat. The real defensibility lies in the agent’s understanding of the Runtime, and in the state, history, and operational boundaries accumulated inside that Runtime.

23. The Runtime’s Hard Problem: Context Engineering

How does a Runtime become usable by an agent? This is the genuinely hard part: context engineering. How do you feed it the right information? My view is clear: building a so-called DBA Agent framework from scratch today will probably produce something worse than simply using Claude Code or Codex. The difficult part is not the wrapper framework. It is providing the right context, permissions, and tool boundaries.

For a DBA Agent, context is not chat history. It is topology, metrics, logs, configuration, and change history. Topology tells it what the system looks like. Metrics show where something is wrong now. Logs reveal what happened. Configuration explains why. Change history shows who just touched what.

The information comes mainly from two sides. One is observation: monitoring, logs, alerts, metrics, and historical trends. The other is control: Inventory, configuration, permissions, Playbooks, CLIs, and backup and recovery interfaces. Connect the two and the agent can graduate from chatting to doing the work.

24. IaC Is the Agent’s Central Dogma

At this point I need to single out one idea, because it is the central secret—the soul—of why DBA Agents work in Pigsty: infrastructure as code. A Pigsty environment is defined by an Inventory. The number of nodes, which one is primary, which are replicas, where monitoring and backups live, which ports and roles exist—all of it is in the configuration inventory.

This inventory is not documentation written after the fact. It is the blueprint from which the entire environment is generated. Once the agent has the blueprint, it knows what the environment looks like. It is not guessing inside an unfamiliar world; it is reading that world’s source code. This is IaC’s real value to an agent: it makes the environment itself readable and condenses it into a single file.

25. Mastery Means Becoming One with the Tool

Now the pieces fit together. In Chinese martial-arts stories, the master swordsman becomes one with the sword. The same is true of a programmer and a keyboard, a veteran driver and a steering wheel, or a DBA and an environment.

A DBA’s ability is not merely the database theory in their head. It comes from becoming one with the environment. Drop a world-class expert into an unfamiliar system, and they may perform worse than an ordinary administrator who has lived in that system for three years. The latter knows where the traps are, which machine is slow, which parameter must not be touched, and which application goes haywire every night.

Agents are no different. Drop Claude Code into a completely unfamiliar Linux environment and it will flounder. Place it inside a deterministic Pigsty Runtime, with the Inventory, monitoring, documentation, and CLI, and it can do a great deal.

26. Read-Only Advice Is Ready; Automatic Execution Requires Caution

That said, let me pour a little cold water on the idea. In a serious production environment, I do not recommend handing the database over to an agent in fully automatic mode from day one. The most credible model today is still a copilot: the agent gathers information, analyzes the problem, proposes a plan, and explains the risks; then a human confirms it. Either the human executes the plan or explicitly authorizes the agent to do so. Destructive and irreversible operations in particular must face hard constraints.

This takes us back to the beginning: AI cannot take the blame for you. Responsibility cannot be transferred, so operations must be confirmed by a human. That is why a DBA Agent should first become a solid copilot instead of leaping straight to aggressive Level 5 autonomy.

Today, a workflow of read-only recommendations from a DBA Copilot, followed by human execution, is mature enough for production. The next step is to make every stage of that workflow more reliable.

Part IV: Extending the Idea—from DBA Agent to Dev Agent

27. Not Just for DBAs: piglet.run

So far I have discussed DBA Agents for enterprise deployments and large PostgreSQL clusters. But there is another audience: individual developers and small teams. They do not necessarily need a complex DBaaS management system. They need a development runtime that works out of the box.

That is the problem piglet.run aims to solve: distill Pigsty’s observable, controllable, and reversible capabilities into a development runtime for individuals and small teams. It takes a Linux virtual machine and configures PostgreSQL, Nginx, monitoring, development tools, Claude Code, Codex, Code Server, and everything else in one shot. Then Coding Agents can work directly inside that environment.

The Runtime prepared for a DBA Agent—an observable, controllable, reversible environment—works just as well for a Dev Agent, perhaps even better.

28. pg.center: A Small, Real Example

Here is one of my own examples. I recently built a small project called pg.center, an unofficial Chinese mirror of postgresql.org. In the past, building something like this was not a small job. You had to find the website repository, fetch content, translate it, generate pages, deploy them, and keep everything synchronized on a schedule.

Today the process is simple. I log in to a cloud server and bring up the Runtime with one command. Nginx, the database, monitoring, and the programming environment are all ready.

Then I open Claude Code and tell it: “I want to build a Chinese edition of the PostgreSQL website. Make a plan first, then execute it.” About a day later, the site is up, with scheduled synchronization and updates.

That is the value of the Runtime. You do not write everything locally and deploy it afterward. You let the agent do the work directly inside a deterministic, production-grade environment.

29. A LAMP Stack for the New Era

This reminds me of the old LAMP stack: Linux, Apache, MySQL, and PHP. A generation of websites launched quickly on that foundation. Times have changed. The P no longer has to mean PHP; it might be Node.js, Go, Python, or whatever language an agent prefers. But several components remain constant: Linux, a database, a web entry point, and monitoring.

So here is another prediction: the agent era will produce a new foundational stack, designed not for traditional programmers but for Dev Agents.

I call it the AI Agent LAMP stack: Linux, Agent, Monitoring, PostgreSQL. This is not a literal recreation of the original LAMP. It is a mnemonic for the agent era: Linux provides the environment, the agent provides execution, Monitoring provides the eyes, and PostgreSQL provides data and state. Pigsty can provide this entire stack.

With it, the barrier to building a website, portal, internal system, or data application falls dramatically. A developer may have only two things left to worry about: buying a domain and renting a server. The agent can handle the rest.

30. The Filesystem Should Be Reversible Too

There is one particularly interesting capability worth mentioning: time travel and environment sharing.

We used JuiceFS to put filesystem state into PostgreSQL. That means your code, configuration, and database content now share a single backup and rollback system. Did the agent make a mess? One-click PITR returns the entire environment, including the filesystem, to where it was five minutes ago. You can also mount the filesystem on Linux, Windows, and macOS, sharing one directory across people and devices.

This is extremely useful for agents. They can experiment freely and roll back with PITR when they get something wrong. What used to be a DBA’s ultimate black magic is becoming available to ordinary users. It gives agents the confidence to experiment boldly.

Part V: Giving the Body to the Community

31. Pigsty Is More Than a DBA Agent’s Body

We can now condense the entire argument into one sentence: on the surface, Pigsty is a PostgreSQL distribution; in essence, it is an Agent Runtime. It places Linux, PostgreSQL, monitoring, backups, high availability, IaC, CLI, and documentation inside one deterministic world.

For a DBA Agent, it is the production environment. For a Dev Agent, it is the development environment. For a Coding Agent, it is an execution environment where it can experiment, verify, and roll back.

32. An Open Proving Ground—Come Play

I welcome anyone interested in building agents to come experiment with Pigsty. Think of it as an open proving ground. It has real PostgreSQL, real Linux, real monitoring, real backup and recovery, real high availability, and real configuration and management interfaces. You do not need to reinvent the wheel from scratch. Whether you are building a DBA Agent or a Dev Agent, Pigsty can serve as a convenient foundation.

If you are an agent developer or user, you do not need to begin by assembling the low-level environment. Just run Claude Code or Codex inside it. Let the agent accumulate knowledge of the environment and distill that knowledge into memories and Skills. It will grow more familiar with the system and more capable over time.

33. An Open-Source, Shared Runtime

In the agent era, the truly valuable thing is not a prompt, a Skills file, or a clever-looking chat interface. All of those will be copied, absorbed, and rapidly commoditized. What is difficult to copy is a complete runtime environment that is stable, transparent, observable, controllable, and reversible.

That is what Pigsty wants to provide: an open-source PostgreSQL Runtime, a world that an agent can truly enter, understand, operate, verify, and learn from. It does not trap the agent in a web demo and ask it to perform. It puts the agent inside real Linux, real databases, real monitoring, real backups, real high availability, and a real operating environment, then tests it in the field.

The future will not have only one agent or one correct answer. Hundreds, then thousands, of agents will emerge in different directions. Every one of them will need a body and an environment in which it can act. Pigsty can become the skeleton of that body.

34. Giving Agents a Body Also Redefines the Human Role

We give agents bodies not to replace people, but to unleash productivity. DBAs should not waste their time repeatedly installing software, running the same health checks, checking the same metrics, or writing the same scripts. Developers should not waste their time configuring databases, Nginx, monitoring, and deployment pipelines again and again. Agents can do this work, and they will keep getting better at it.

That does not mean people become obsolete. Quite the opposite: the more work agents can do, the more humans must move up the stack. People define goals, design systems, judge risk, set boundaries, and bear responsibility. Humans are no longer the ones tightening every screw by hand. They decide how the machine should operate, who is accountable when it fails, and which decisions must never be left to the machine.

Model generations will turn over, and waves of agents will come and go. What endures is the runtime that is reproducible, auditable, reversible, and trustworthy. Pigsty wants to build that foundation.

Do not think of it as merely a PostgreSQL distribution. Put your agent in an observable, controllable, reversible environment. Let it run, experiment, and verify. Let it grow the body it needs to enter production for real.

Thank you.

1.8 - Put Your AI Agent's State in a Database

Originally published on VONNG.

A year ago, I wrote an article called PGFS: Using a Database as a Filesystem. It started with a request from the Odoo community: make files and the PostgreSQL database recoverable together with point-in-time recovery, so both could be rolled back to the same moment.

The solution has worked quite well. It delivers entirely in software a capability that once required expensive dedicated continuous data protection hardware: rolling the filesystem and database back together to any point in time. Performance is respectable too—more than enough for applications such as Odoo and Dify.

But recently I discovered that PGFS was attracting an unexpected group of users. They were not running ERP systems. They were using it to store AI agent state.

The idea is simple: PGFS mounts a PostgreSQL database as a local directory. Reading from or writing to that directory actually reads from or writes to a remote database. Put the AI agent’s working directory, configuration files, and memory there, and all of its state lives in PostgreSQL.

That made me realize PGFS may be far more useful than I originally imagined. I know of at least one company building a commercial OpenClaw distribution that already uses PGFS as its underlying shared-memory mechanism.

Does an Agent Actually Need a Database?

Before discussing the implementation, let us start with the “why.” This question comes up constantly. My friend Jiang and I argue about it all the time: AI agents do not need databases, he says. SQLite is enough.

For a consumer running one agent on one local machine, he may be right. One person runs Claude Code, keeps its state under .claude/, and manages the code properly with Git. No problem. Using PostgreSQL for agent state in that scenario really can feel like looking for a nail because you happen to have a hammer.

But once the scenario becomes even slightly more complex, a database is unavoidable. As Turing Award winner and Postgres creator Mike Stonebraker puts it, this is the path AI agents will inevitably take.

What counts as “slightly more complex”?

Multi-agent collaboration. You begin assigning work to parallel subagents: one writes code, another writes tests, and a third reviews the result. They need to communicate task status and share context. A Markdown file as a task queue? It can work, but it is fragile.

From one person to a team. Coordination is easy to ignore when you are vibe coding alone. But once three or five people on a team each have their own agents working, you need somewhere to coordinate them. As soon as collaboration crosses machines, people, or organizations, a database becomes much more convenient than a directory on someone’s laptop.

Enterprise use. Enterprise applications inherently require centralized storage, auditing, and access control. You need continuous data protection so you can restore to any point in time. You need flexible snapshots, forks, and sharing. You also need to handle concurrent access and data consistency correctly.

The consumer endgame. Today your agent runs on one machine and has that environment to itself. But if you genuinely want something like Jarvis—an agent that runs across all your devices and provides one consistent experience—those agents will necessarily need shared memory.

As complexity grows, sooner or later you will reach for a database to solve these problems—unless you intend to reinvent a bad database on top of the filesystem.

So what unique value can a database offer an AI agent?

I see two killer features.

Killer Feature One: A Time Machine

The first is point-in-time recovery (PITR).

When an agent breaks something in today’s AI-agent workflows, recovery can be difficult. If the agent relies entirely on the filesystem and Git for state, you may be fine if you work only with code, maintain a disciplined Git workflow, and commit and push promptly. But in reality, a great deal of state never enters Git: agent configuration, intermediate artifacts, temporary data, working memory, and more. One bad operation can destroy it permanently.

We have already seen cases of Claude deleting code repositories, never mind data that was not under version control at all.

You might say, “I can take snapshots with Git or ZFS.” You can, but there are two problems. First, snapshots represent discrete points in time. You can return to “the previous snapshot,” but not necessarily to the precise moment 3 minutes and 27 seconds ago—say, one second before the accidental deletion. Second, you must manage those snapshots explicitly: when to create them, how long to retain them, and how to clean them up. That is an operational burden of its own.

Historically, there were only two ways to get the ability to return to any point in time: buy expensive CDP hardware, or build a complex logging system yourself.

PGFS offers a third option: turn every filesystem write into a database write, then inherit PITR from PostgreSQL’s write-ahead log.

More concretely, when you write a file into a PGFS-mounted directory, its data is actually written into PostgreSQL’s jfs_blob table. Filesystem operations and database operations share the same WAL stream. When you perform PITR, the database and filesystem return to the same target time, down to the microsecond timestamp of each operation.

That gives your agent a time machine: no matter what it does, you can restore everything to any point in time. Code, data, configuration, and memory all roll back together, with no inconsistency between them.

This also unlocks another capability: instant cloning and branching. Because the code’s state is ultimately data inside the database, you can create a new database instance from any point in time, with its filesystem state and database state perfectly aligned. It is like a Git branch, except the business data in the database branches with the code. Different agents can work on different “branches” without interfering with one another. Broke something? Roll back. Want to try another approach? Fork a fresh environment. A filesystem-only design cannot do this.

For AI agents, it is hard to overstate the value of this capability. It gives you an “unlimited undo” safety net—or, in video-game terms, a save system you can load at any time.

Killer Feature Two: A Shared Brain

If you have only one person and one agent, there is indeed nothing to share. But once you start using agents and subagents in parallel, they need an efficient place to communicate.

How does the usual single-machine setup work today? You write a Markdown file in the project directory as a to-do list, manually assign tasks, and send subagents off to execute them. It works, barely, for one person. But put those tasks in a database table, let every agent claim work, update status, and report results there, and you have a natural task-scheduling hub. There is no need for file locks or polling; the database’s MVCC and LISTEN/NOTIFY handle concurrency naturally.

More importantly, a local directory is awkward to share with other people. You can use FTP or NFS, but configuration is cumbersome and security becomes another concern.

PGFS provides a much cleaner sharing model. Imagine this architecture:

1. You run Pigsty, including PostgreSQL, on a cloud server.
2. You create a PGFS mount point there, such as /fs.
3. You put all project code, agent configuration, and shared memory under that directory.
4. Anyone on the team who has the database connection string can mount the directory on their own machine with one command.

One connection string and one mount command let multiple people, machines, and agents share the same workspace.

That is how I work today: I keep all of my projects in a Pigsty-based monorepo. I can work directly with Claude Code on the cloud server while also mounting the cloud-hosted PGFS locally for local reads and writes. Multiple platforms, multiple instances, seamless synchronization.

Each person can own a subproject while collaborating inside one overall repository.

Now look further ahead. If you really want a Jarvis-style digital assistant, it will need a central place to store state. You cannot give every agent an isolated memory. Otherwise, you do not get one assistant; you get a crowd of underlings that know nothing about one another.

The most natural way for multiple agents to share memory is to give them a hub: a cloud VM running Pigsty, with the database mounted locally through a URL. Every agent can read and write shared state while retaining its own private memory.

There are plenty of other benefits beyond these two: ACID transactions, high availability, observability, backup and recovery, replication, CDC tooling, and more. I will not expand on all of them here.

How to Build It: Pigsty’s JUICE Module

That covers the “why.” Now for the “how.” The underlying capability has existed for a year; I packaged JuiceFS for Pigsty back then. Pigsty 4.0 officially introduced the JUICE module, turning the entire process into declarative configuration and one-command deployment.

What Is JuiceFS?

JuiceFS is a high-performance, POSIX-compatible distributed filesystem. Its architecture is straightforward: a metadata engine plus a data-storage backend. The metadata engine manages the directory tree and file attributes; the storage backend holds file contents.

The core idea behind PGFS is this: JuiceFS can use PostgreSQL as both its metadata engine and its data-storage backend. All file metadata and contents live in PostgreSQL and share the same WAL stream. (TimescaleDB recently released TigerFS, which offers similar functionality, but it is less mature. I have packaged and integrated that as well.)

Declarative, One-Command Deployment

Pigsty’s vibe configuration template already includes a working example. Run these commands on a fresh Linux server, and you will have a predefined PGFS mounted at /fs:

curl -fsSL https://repo.pigsty.io/get | bash
cd ~/pigsty
./configure -c vibe -g   # Use vibe mode and generate random passwords
./deploy.yml             # Deploy infrastructure and PostgreSQL
./juice.yml              # Deploy the JuiceFS filesystem

Every read and write under the default /fs directory lands in the database. You can mount that same database at another path—or at local mount points on multiple computers—to share the directory. All of it is defined by this short configuration:

juice_instances:
  jfs:
    path: /fs
    meta: postgres://dbuser_meta:[email protected]:5432/meta
    data: --storage postgres --bucket 10.10.10.10:5432/meta \
      --access-key dbuser_meta --secret-key DBUser.Meta
    port: 9567

That is all. The system automatically formats the JuiceFS volume, mounts it, configures it to start at boot, and integrates monitoring.

You can easily use the same pattern to define multiple JuiceFS instances, or mount one instance on several different machines:

app:
  hosts:
    10.10.10.11: {}
    10.10.10.12: {}
  vars:
    juice_instances: {...}

Better still, the shared mount is not limited to those Linux servers. macOS and Windows users can mount the cloud-hosted PGFS locally too:

juicefs mount "postgres://dbuser_meta:[email protected]:5432/meta" ~/work -d

One connection string is the entry point to your “shared cloud drive.” It is much simpler than NFS or FTP. I am preparing a one-click setup script for macOS and Windows: enter a URL, and it will configure everything for you.

Experienced users will immediately see the trick: move the dot-directories that Claude Code, Codex, and OpenClaw keep under your home directory onto the mounted shared workspace, then symlink them back to their original locations. Your agent state now lives in the database.

And the best part is that performance is quite respectable. PGFS will certainly deliver less throughput than a native filesystem, but actual measurements are not bad: file reads and writes deliver roughly 100 MB/s, and JuiceFS has a local caching mechanism as well. That is more than enough for workloads such as Odoo and coding agents.

Of course, the real highlight is the black magic of rolling the entire environment back to any point in time with a single PITR operation after an agent wrecks it.

Conclusion

Back to the original question: does an AI agent actually need a database?

For a simple single-user, single-machine, single-agent setup, not necessarily; SQLite may be enough. But the agent world is becoming more complex: multi-agent collaboration, shared team environments, persistent state, and recovery from failure. Once those requirements appear, the database stops being optional and becomes infrastructure.

Through Pigsty’s JUICE module, PGFS gives AI agents two killer capabilities:

1. A time machine: PITR to any point in time, restoring code, data, configuration, and memory together. It also enables instant clones and branches, so agents can experiment in parallel from different “save points.”
2. A shared brain: multiple agents, people, and machines share the same workspace and memory—with one connection string and one mount command.

A filesystem-only design cannot provide these two capabilities. They once required CDP hardware with a six-figure price tag. Now? One cloud server, one open-source stack, four commands, and no license bill.

This is the right way to use a database in the AI era.

1.9 - Pigsty Goes Global: 1.44M Visitors, Zero Ad Revenue

Originally published on VONNG.

Traffic on pigsty.io jumped by roughly an order of magnitude over the last month. I opened the Cloudflare dashboard today and had to stare at it for a second.

1.44 million unique visitors, 18.11 million page views, 1.1 TB of traffic.

That is over 30 days. For the documentation site of an open source project maintained by one person.

I asked Claude to benchmark the numbers. Its answer was basically: this looks like the traffic profile of a mid-sized SaaS product.

Which is amusing, because I did not build a SaaS product. I built a PostgreSQL distribution, and it is for local deployment.

So where is all this traffic coming from?

By country, the US is first with 13.98 million requests, far ahead of everyone else. Vietnam is second with 3.03 million, followed by the UK, France, Singapore, Germany, and then China in sixth place. This is an open source project built by a Chinese developer, and Chinese traffic is only sixth. The site reached users in 177 countries and regions. The UN only has 193 member states.

I still do not know why Vietnam is so enthusiastic, but several Vietnamese people added me on LinkedIn recently, so clearly something is happening there.

No Ads, No Monetization

Claude also did the obvious back-of-the-envelope calculation. At this traffic level, a vanilla Google AdSense setup would probably generate something like $5,000 to $10,000 per month. If I sold sponsorship placements directly to database vendors, it could be several times higher.

I did none of that. No ads. No popups. 1.44 million people came and went, and I made exactly zero dollars from the traffic.

And this is only the international site, pigsty.io. There is also the domestic pigsty.cc site behind a China CDN, and those numbers are not even included here.

That said, I am used to this pattern. My WeChat public account is already one of the larger personal database accounts in China. The backend fills up with “business cooperation” messages every day, and I still have not taken a single sponsored deal.

The GitHub Side of the Story

Of course, a decent amount of Cloudflare traffic is probably crawler traffic. But even if only ten percent is real human traffic, that is still far beyond what I expected for an open source project.

And traffic is only one signal. On GitHub, Pigsty has also been growing quickly and is about to cross 5,000 stars.

Among PostgreSQL distributions, Pigsty is now third. At this rate it should reach second before long. Right now number one is EDB’s CloudNativePG, but the two projects sit in different niches anyway: they are doing Kubernetes-native PG, while I am doing Linux-native PG.

The difference is that EDB is one of the old giants of the PostgreSQL world, with a large team and a long list of contributors behind CloudNativePG.

Pigsty is just me. Literally a database one-man business. The fashionable term now is OPC: One Person Company.

How Far Can One Person Go?

Within the Chinese PostgreSQL ecosystem, Pigsty is probably the open source project with the strongest international reach built by a domestic vendor or developer. Its GitHub stars are already comfortably ahead of several PostgreSQL kernel projects backed by Alibaba, Huawei, and Tencent.

Getting here as a solo builder is still a little surreal.

In a few weeks it will be exactly four years since I went independent. Pigsty started as a one-person project. Technology, product, docs, marketing, sales, consulting, delivery: I did all of it myself.

To be clear, it has not been easy. But the timing helped. AI made it realistic for one person to do work that used to require a team. If you want to run an OPC, this is a much better era than the one before it.

Where Things Stand Now

Honestly, I like the current state of affairs.

The consulting business keeps growing and easily covers expenses. Customer retention is perfect. The global user base keeps growing organically. There is no fundraising pressure, no KPI theater, no boss, no morning standup.

I write the code I want to write, build the product I want to build, and work with customers worth working with.

Four years ago this was just a tool I built for myself. Now it has users across 177 countries and regions. That fact says something:

if you make something genuinely good, the world will eventually find it.

You do not necessarily need a team. You do not necessarily need a marketing budget. Build something solid, put it out there, and let the tailwinds arrive when they arrive.

That is what open source does. You give your best work away for free, and the world pays you back in its own currency. That currency is not always money. Often it is something more valuable: trust.

Trust from users in 177 countries and regions.

That is worth more than ad revenue.

1.10 - Pigsty v4.2: 12 Kernels in Bloom

Originally published on VONNG.

GitHub Release | Release Note

Pigsty v4.2 is officially released, hot on the heels of PostgreSQL’s emergency out-of-band minor updates.

This release ships three brand-new PG kernels — the graph database AgensGraph, the multi-master distributed pgEdge, and the MPP data warehouse Cloudberry — while rebuilding three existing kernels: Babelfish, OrioleDB, and OpenHalo. With these additions, Pigsty now supports a total of 12 kernels.

With a single configuration file, you can deploy all these different flavors of PostgreSQL as enterprise-grade database services — complete with monitoring, high availability, point-in-time recovery, and Infrastructure as Code. That is essentially what a “Meta PG Distribution” means.

A Garden of Kernels

PostgreSQL is renowned for its extreme extensibility. The ecosystem offers over 1,000 extensions, and Pigsty provides 461 of them out of the box.

But some capabilities are beyond what extensions can achieve — namely, custom syntax. If you want native Oracle PL/SQL, SQL Server T-SQL, MongoDB’s BSON wire protocol, or Cypher graph queries inside PostgreSQL — not emulated through function calls, but as first-class syntax — you need to modify the kernel. That is why Pigsty not only provides the largest collection of extensions in the ecosystem, but also supports different kernel forks.

Using these kernels in Pigsty is virtually identical to using vanilla PostgreSQL — the same deployment workflow, the same monitoring dashboards, the same HA mechanisms, the same backup and recovery. The only difference is changing one pg_mode value in your configuration file. A one-line config change, an engineering grand unification.

Twelve kernels, one config file. Let’s walk through them one by one.

Vanilla PostgreSQL

This round of PostgreSQL minor releases deserves a special mention.

The 18.2 series introduced regression bugs related to substring and WAL replay — fixing a vulnerability inadvertently created new bugs. The community reacted swiftly, shipping emergency patches 18.3 / 17.9 / 16.13 / 15.17 / 14.22 just two weeks later. Pigsty’s approach remains the same as always — the day after new versions drop, offline packages are ready, all extensions are recompiled and verified, and documentation is updated. All you need to do is run a single command.

The total extension count also climbed to 461.

If you prize maximum extensibility and the best stability, vanilla PostgreSQL remains the optimal default choice. Pigsty supports PG 14 through PG 18 across their active lifecycle. Worth noting: this is the last release to support PG 13; the minimum version will be raised to PG 14 going forward.

pgEdge: Native Multi-Master Replication

pgEdge is the heavyweight newcomer in this release.

Traditional PostgreSQL high availability follows a primary-standby model — writes can only go to the primary node. pgEdge’s core extension, Spock, breaks this constraint: every node in the cluster can handle reads and writes, with data asynchronously synchronized between nodes via logical replication, and conflicts resolved automatically through configurable strategies.

Strictly speaking, pgEdge is not an entirely new kernel but rather a multi-master solution built on standard PostgreSQL + the Spock extension. However, since some low-level multi-master capabilities require kernel patches (which have not yet been merged into the PostgreSQL mainline), it currently ships as a “patched kernel + extension” combination. This is similar to OrioleDB and Percona TDE — if the PostgreSQL mainline eventually merges these patches, they could all transition to pure extension form. That is a very promising trend to watch.

I’m quite bullish on this project. The pgEdge team includes several PostgreSQL community kernel veterans with deep technical expertise. Its open-source journey is also worth mentioning: previously it used a Confluent-style Source Available license (pgEdge Community License), which was not strictly open source. But in September 2025, it fully transitioned to the PostgreSQL License.

One nuance to be aware of, though: the source code is under the PostgreSQL License, but the official binary packages remain under a commercial license. Specifically, development use is free, but production use requires a paid subscription.

I built the packages directly from the PostgreSQL-licensed source code myself — creating patched PostgreSQL kernel packages and adapting them for all major operating systems that Pigsty supports. No external dependencies; just install from the Pigsty repo. No production licensing issues. Of course, if you want their cloud service and commercial support, you’re welcome to go support them.

pgEdge consists of three core extensions:

• Spock 5.0.5: The multi-master logical replication engine; every node handles reads and writes.
• Lolor 1.2.2: Large object logical replication.
• Snowflake 2.4: Distributed sequence number generation.

For conflict resolution, pgEdge provides multiple strategies: simple “last-write-wins” (LWW), dedicated CRDT-based approaches, conflict log tables, and user-defined custom strategies. If you have globally distributed needs — say, a node each in Beijing, Frankfurt, and Virginia, with users reading and writing from the nearest one — this multi-master model is an excellent fit. It essentially brings native CockroachDB/TiDB-style multi-write capabilities into the PostgreSQL ecosystem, except the foundation is still the PostgreSQL you know and love.

To use it in Pigsty: configure -c pgedge.

AgensGraph: Graph Database

AgensGraph positions itself as a multi-model graph database built on PostgreSQL — natively supporting both relational and property graph models within a single engine, rather than starting from scratch like Neo4j. The project is led by the Korean team at Bitnine.

Some may ask: doesn’t the PostgreSQL ecosystem already have Apache AGE as a graph extension? Why bother forking the kernel?

There is an interesting backstory here: AGE and AgensGraph were actually created by the same team. They originally built AgensGraph as a kernel fork, which earned around 1,000+ stars. Later, they tried implementing similar functionality in extension form, creating AGE and donating it to Apache. The extension form turned out to be far more popular, garnering 4,000+ stars. AGE went through a brief maintenance hiccup last year but has since resumed updates, releasing version 1.7.0 targeting PG 17/18.

So what is the value of the fork? At least four things:

First, native syntax. In AGE, you execute Cypher queries through function calls (passing query strings as arguments). In AgensGraph, you write CREATE GRAPH directly — Cypher is first-class syntax.

Second, storage optimization. Its storage engine is specifically optimized for graph properties, theoretically yielding better performance (though I have not personally benchmarked it yet).

Third, unified query optimization. Cypher, JSON, and SQL queries are handled uniformly at the optimizer level — a very interesting native implementation approach.

Fourth, vector compatibility. AgensGraph recently announced pgvector compatibility, meaning you can do Graph RAG — combined graph + vector retrieval — within a single database. This is an extremely hot frontier area right now. I have not yet packaged this specific vector plugin, but may add it later.

Of course, the cost of the fork path is also obvious: keeping up with the PG mainline is extremely difficult. PG is now at 18, while AgensGraph is still based on PG 16. This is the eternal fate of forks — always one or two major versions behind.

To use it in Pigsty: configure -c agens.

Cloudberry: MPP Data Warehouse

Cloudberry is the third new kernel in this release. It is an Apache project led by the HashData team, essentially a fork of Greenplum 7 — but with significant improvements, such as upgrading the kernel from Greenplum’s PG 12 to PG 14, filling in many useful newer features.

After Cloudberry 2.0 was released, official binary packages were no longer provided — version 1.6 previously had RPMs, but now even those are gone. After waiting several months with no sign of the team addressing this, I decided to build them myself with Claude’s help. The packaging process went smoothly overall, requiring only minor code changes and patches on some newer operating systems. Previously there were only RPMs; now DEBs are available too, across all 14 Linux distributions that Pigsty supports.

As for Cloudberry/Greenplum deployment scripts and monitoring, we actually had those back in Pigsty v1.4, but removed them later due to very low usage. After all, the scale needed for an MPP data warehouse is beyond most organizations. So after careful consideration, we are offering it as a Beta module on demand — the packages are built and available in the repo for direct download; full deployment playbooks will be provided in a future release as appropriate.

Babelfish: SQL Server Compatibility

Having covered the three new kernels, let’s talk about the three rebuilt kernels.

Babelfish is AWS’s open-source SQL Server compatibility layer — it lets PostgreSQL understand T-SQL syntax and the TDS protocol, so your SQL Server applications can connect to PostgreSQL without changing drivers or most queries. Great project, but the build process is notoriously complex — so complex that there is an entire open-source project, WiltonDB, dedicated to just this task.

Previously, I took the easy route and used WiltonDB’s packages. Honestly, their package quality always left me a bit uneasy: no support for the full Debian series or EL10, a dependency system that differs from standard PG, and the version was stuck on PG15 — while upstream Babelfish already supported PG17.

This time I bit the bullet and built it myself. With the packaging experience gained from the other kernels, this turned out to be straightforward — bundling Babelfish’s four core extensions into a single package alongside a patched kernel package, ready to go. It no longer depends on the external WiltonDB repository and installs directly from the Pigsty repo. The version has been upgraded to Babelfish 5.5 + PG17.

To use it in Pigsty: configure -c mssql.

OrioleDB: New Storage Engine

OrioleDB is the next-generation PostgreSQL storage engine project acquired by Supabase, aiming to fundamentally solve MVCC bloat — replacing the traditional dead tuple + VACUUM mechanism with an Undo Log approach.

This rebuild upgrades to OrioleDB Beta14, built on OriolePG 17.16. A key advancement in this version is the addition of PITR incremental backup and recovery support. It is still in Beta and not recommended for critical production workloads. But as one of the future evolution paths for PostgreSQL storage engines, it is well worth continued attention and experimentation.

To use it in Pigsty: configure -c oriole.

OpenHalo: MySQL Wire-Protocol Compatibility

OpenHalo is the third rebuilt kernel. It provides MySQL wire-protocol compatibility — you can simultaneously use MySQL clients and PG clients to read from and write to the same database, which is a very interesting capability.

Developed by the YiJing XiHe team, they are one of the few domestic Chinese database companies that quietly does solid work and is willing to open-source the results. That is genuinely rare.

Changes in this update:

• Version upgraded from PG 14.10 to PG 14.18
• Version number officially updated to 1.0, with naming adjusted to follow Pigsty’s packaging conventions

Although the PG 14 baseline is a bit dated, it is a worthwhile option for MySQL migration scenarios.

To use it in Pigsty: configure -c mysql.

The Other Six Regulars

Besides the six kernels added or rebuilt in this release, Pigsty has six long-standing “regulars”:

IvorySQL (pg_mode: ivory) — Oracle PL/SQL compatible kernel by Highgo, currently based on PG 18.1.

Percona TDE (pg_mode: tde) — Transparent data encryption, meeting the hard compliance requirement of “encryption at rest.” Updates trail the PG mainline slightly; future releases will catch up.

PolarDB (pg_mode: polar) — Alibaba’s open-source shared-storage PG kernel, with minor version updates. Notably, this release drops support for PolarDB-O (the version with domestic compliance certification); the open-source edition retains only the community PG version.

Citus (pg_mode: citus) — Microsoft’s distributed extension, with the official release of version 14.0.0, now supporting PG 18.

Ferret / DocumentDB (pg_mode: mongo) — MongoDB wire-protocol compatibility, letting you connect to PostgreSQL directly with MongoDB drivers.

Supabase self-hosted template has also been routinely updated to the latest version.

One Config, Ten Kernels in Flight

After all this talk about kernels, the most fun part is actually this: we created a demo/kernels.yml config file — if you have 10 VMs, you can use this template to spin up 10 different PG kernels with a single command.

Each cluster gets its own monitoring dashboards, high availability, and backup recovery, managed just like 10 standard PostgreSQL instances. Pure showing off, but also a great reference template: if you want to mix-deploy multiple kernels within a single Pigsty installation, this shows exactly how to configure it.

This is not an architecture diagram on a slide deck. It is running code.

Other Improvements

Beyond the kernel showcase, v4.2 includes several notable engineering improvements:

Redis directory normalization: The default directory changes from /data to /data/redis. Existing configs still using /data need to be updated before upgrading; deployment will block the old path.

Configure script improvements: Supports -o absolute path output with auto-created directories; region detection is now tri-state (domestic/international/offline fallback), fixing the behind_gfw() hang issue.

pgBackRest initialization resilience: stanza-create now retries (2 attempts, 5-second interval), mitigating lock contention with archive-push. If you have hit this issue, you know how annoying it is.

Supabase stack upgrade: PostgREST 14.5, Vector 0.53.0, and S3 access key variables are now properly included.

Vibe template updates: Ships @anthropic-ai/claude-code, @openai/codex, happy-coder, and more — AI coding sandbox out of the box.

Infrastructure routine upgrades: Grafana 12.4, Prometheus 3.10, VictoriaMetrics 1.136, etcd 3.6.8, Kafka 4.2, among others. Note that Grafana 12.4 changes data link merge behavior; review custom dashboards accordingly.

Homepage redesign: Previously hacked together with Claude Code, and people rightfully complained it was ugly. This time Codex gave it an optimization pass, and it looks much better. Will continue polishing when time permits.

Looking Ahead

As an open-source project, I think Pigsty has reached a fairly mature state. The focus going forward will gradually shift to sub-projects:

Pig CLI has recently gained many powerful features — wrapping PostgreSQL, Patroni, PgBouncer, and pgBackRest management into a unified command-line tool, convenient for DBA Agents like Claude Code to invoke. This kind of CLI designed simultaneously for human DBAs and AI Agents is what I call an Agent-Native CLI.

DBA Agent work has also progressed — I have recently written some Claude Skills and prompt templates that make the Pigsty environment perceptible to AI tools. This way you can drop Claude Code into a Pigsty environment and let it work for you.

Pigsty itself will continue to follow the PG minor release cadence. The next version may officially include the Cloudberry deployment playbook, plus local SMTP server support (maddy / stalwart). No rush for big new features — the current architecture running stably is just fine.

v4.2.0 Release Note

Highlights

• Aligned with PostgreSQL out-of-band minor updates: 18.3, 17.9, 16.13, 15.17, 14.22.
• Total PostgreSQL extension coverage reaches 461 packages.
• Kernel updates across Babelfish, AgensGraph, pgEdge, OriolePG, OpenHalo, and Cloudberry.
• Babelfish template now uses a Pigsty-maintained PG17-compatible build, with no WiltonDB repo dependency.
• Supabase images and self-hosted templates are refreshed to the latest stack, using Pigsty-maintained pgsty/minio.

Major Changes

• mssql now defaults to Babelfish PG17 (pg_version: 17, pg_packages: [babelfish, pgsql-common, sqlcmd]) and no longer requires an extra mssql repo.
• Kernel install paths are normalized in pg_home_map: mssql -> /usr/babelfish-$v/, gpsql -> /usr/local/cloudberry.
• package_map adds a dedicated cloudberry mapping and fixes babelfish* aliases to versioned RPM/DEB package names.
• Redis data root default changes from /data to /data/redis; deployment blocks legacy defaults, while redis_remove keeps backward-compatible cleanup.
• configure now supports absolute -o output paths with auto-created parent directories, tri-state region detection (CN/global/offline fallback), and a fix for behind_gfw() hangs.
• Debian/Ubuntu default repo URL mappings (updates/backports/security) and China mirror components are corrected to prevent bootstrap package failures.
• Supabase stack is updated (including PostgREST 14.5 and Vector 0.53.0) and now includes missing S3 protocol credential variables.
• Rich/Sample templates explicitly define dbuser_meta defaults; node.sh systemd completion is simplified.
• pgbackrest stanza initialization now retries (2 attempts, 5-second interval) to reduce lock contention with archive-push.
• Vibe template now ships @anthropic-ai/claude-code, @openai/codex, and happy-coder, and includes age in the default example.

PG Software Updates

• PostgreSQL 18.3, 17.9, 16.13, 15.17, 14.22
• RPM Changelog 2026-02-27
• DEB Changelog 2026-02-27
• Core upgrades: timescaledb 2.25.0 -> 2.25.1, citus 14.0.0-3 -> 14.0.0-4, pg_search -> 0.21.9
• New/rebuilt: pgedge 17.9, spock 5.0.5, lolor 1.2.2, snowflake 2.4, babelfish 5.5.0, cloudberry 2.0.0
• Kernel-side updates: oriolepg 17.11 -> 17.16, orioledb beta12 -> beta14, openhalo 14.10 -> 1.0(14.18)

Infrastructure Software Updates

API Changes

• pg_mode now includes agens and pgedge.
• mssql defaults are updated to pg_version: 17 and pg_packages: [babelfish, pgsql-common, sqlcmd].
• Kernel/package alias mappings are updated in pg_home_map and package_map (Babelfish, OpenHalo, IvorySQL, Cloudberry, pgEdge family).
• redis_fs_main now defaults to /data/redis, with deployment guardrails and backward-compatible cleanup behavior.
• configure output path handling and region detection logic are updated, with offline fallback warnings and unified SSH probe timeouts.
• grafana.ini.j2 is updated for Grafana 12.4 config changes and deprecations.

Compatibility Notes

• If existing Redis configs still use redis_fs_main: /data, migrate to /data/redis before deployment.
• Grafana 12.4 changes data link merge behavior. This release moves key links into field overrides; review custom dashboards accordingly.

26 commits, 122 files changed, +2,116 / -2,215 lines (v4.1.0..v4.2.0, 2026-02-15 ~ 2026-02-28)

Checksums

24a90427a7e7351ca1a43a7d53289970  pigsty-v4.2.0.tgz
d980edf5eeb0419d4f1aa7feb0100e14  pigsty-pkg-v4.2.0.d12.aarch64.tgz
24bc237d841457fbdcc899e1d0a3f87e  pigsty-pkg-v4.2.0.d12.x86_64.tgz
e395b38685e2ecbe9c3a2850876d9b7b  pigsty-pkg-v4.2.0.d13.aarch64.tgz
c5c8776f9bead9f29528b26058801f83  pigsty-pkg-v4.2.0.d13.x86_64.tgz
28ea40434bd06135fc8adc0df1c8407d  pigsty-pkg-v4.2.0.el10.aarch64.tgz
58ad715ac20dc1717d1687daecfcf625  pigsty-pkg-v4.2.0.el10.x86_64.tgz
008f955439ea311581dd0ebcf5b8bd34  pigsty-pkg-v4.2.0.el8.aarch64.tgz
2acfd127a517b09f07540f808fe9547a  pigsty-pkg-v4.2.0.el8.x86_64.tgz
58e62a92f35291a40e3f05839a1b6bc4  pigsty-pkg-v4.2.0.el9.aarch64.tgz
d311bfdf5d5f60df5fe6cb3d4ced4f9c  pigsty-pkg-v4.2.0.el9.x86_64.tgz
c98972fe9226657ac1faa7b72a22498b  pigsty-pkg-v4.2.0.u22.aarch64.tgz
44a174ee9ba030ac1ea386cf0b85f6e7  pigsty-pkg-v4.2.0.u22.x86_64.tgz
143e404f4681c7d0bbd78ef7982cd652  pigsty-pkg-v4.2.0.u24.aarch64.tgz
00dfa86f477f3adff984906211ab3190  pigsty-pkg-v4.2.0.u24.x86_64.tgz

v4.2.1

A maintenance release that adds 3 new extensions.

Major Changes

• New Extensions: pg_eviltransform is added to the GIS package group, pg_pinyin to the FTS group, and pg_qos to the admin group — all for PG 14–18.
• PG13 Removed: All pgdg13, pgdg13-nonfree repo entries and PG13 package aliases (pg13-*) are removed from every platform variant (EL7/8/9/10, Debian 12/13, Ubuntu 22/24, both x86_64 and aarch64).
• Config templates (fat.yml, pro.yml, dev.yml, el.yml, debian.yml) no longer reference PG13 packages or repos. Extension version comments are updated to reflect PG 14–18 coverage only.
• Percona Repo: Origin URL updated from ppg-18.1 to ppg-18.3 to track the latest Percona PostgreSQL distribution.
• Nginx Repo: Module tag for the Nginx upstream APT repo corrected from infra to nginx on Debian/Ubuntu platforms.
• UV Venv Fix: roles/node/tasks/pkg.yml now checks for an existing virtualenv before running uv venv, preventing redundant re-creation and potential errors on re-provisioning.
• Docker Image: less is added to the Pigsty Docker image base packages.
• Demo Config: Default firewall rules in el.yml and debian.yml demo configs now include port 5432 for direct PostgreSQL access.

Compatibility Notes

PostgreSQL 13 reached its end of life on 2025-11-13. The PGDG YUM repository has archived and removed the pg13 / pg12 directories. If you install Pigsty on EL systems (even without using PG 13), repo access failures may cause installation or update errors.

You can either upgrade directly to Pigsty v4.2.1, or manually edit the repo_upstream_default variable in your corresponding OS file under roles/node_id/vars/ and remove the pg13 repo line.

Additionally, EL8 remains in the Pigsty compatible OS list, but starting from this release, offline packages for EL8 will no longer be published.

No other breaking API or configuration changes in this release.

7 commits, 84 files changed, +4,925 / -5,351 lines (v4.2.0..v4.2.1, 2026-03-04 ~ 2026-03-06)

PostgreSQL Package Updates

Infrastructure Package Updates

Checksums

262b7671424a38b208872582fe835ef8  pigsty-v4.2.1.tgz
62edcca1d1e572a247be018e1c26eda8  pigsty-pkg-v4.2.1.d12.aarch64.tgz
1d55367e2fd9106e6f18b7ee112be736  pigsty-pkg-v4.2.1.d12.x86_64.tgz
f122b1e5ba8a7ae8e3dc6e6dd53eba65  pigsty-pkg-v4.2.1.d13.aarch64.tgz
617a76bfc8df8766e78abf24339152eb  pigsty-pkg-v4.2.1.d13.x86_64.tgz
908509b350403ad1a4a27a88795fee06  pigsty-pkg-v4.2.1.el10.aarch64.tgz
70cb4afd90ed7aea6ab43a264f8eb4a8  pigsty-pkg-v4.2.1.el10.x86_64.tgz
98fbd67334f5c674b12e6af81ef76923  pigsty-pkg-v4.2.1.el9.aarch64.tgz
687fa741ccd9dcf611a2aa964bcf1de8  pigsty-pkg-v4.2.1.el9.x86_64.tgz
a2a30f4b1146b3e79be91d5be57615b6  pigsty-pkg-v4.2.1.u22.aarch64.tgz
7a1f571bd8526106775c175ba728eee1  pigsty-pkg-v4.2.1.u22.x86_64.tgz
a5574071bac1955798265f71ad73c3d4  pigsty-pkg-v4.2.1.u24.aarch64.tgz
59a7632c650a3c034f1fe6cd589d7ab5  pigsty-pkg-v4.2.1.u24.x86_64.tgz

1.11 - Pigsty v4.1: Speed Is the Moat

Originally published on VONNG.

GitHub Release | Release Note

If there is one takeaway from this release, it is that speed matters. On February 12, 2026, the PostgreSQL community released 18.2 / 17.8 / 16.12 / 15.16 / 14.21 on the regular minor cadence. As far as I could tell, the teams with production-grade support ready on the same day included AWS RDS, EDB, and Pigsty.

For an independent open-source project to keep pace with the world’s largest cloud vendor and a long-standing PostgreSQL leader – that is the story I hope v4.1 can tell.

Why Speed Matters So Much

After years of building a database distribution, one lesson keeps coming back: what users need most is not more features – it is confidence that the project will be there when it counts.

Where does that confidence come from? Less from feature lists, and more from showing up reliably at the moments that matter. PostgreSQL minor releases carry bug fixes, stability improvements, and security patches. They are not optional upgrades. Every day of delay is another day users remain exposed.

In practice, many distributions follow a well-known pattern: upstream ships, internal testing begins, packaging takes a while, and a couple of months later a blog post announces support for the latest version. By that point, users who needed the update have often already upgraded on their own. “Support” can end up feeling more like a formality than meaningful protection.

The experience I would love to provide is the opposite: follow-up so prompt that users never have to worry about it. PostgreSQL ships a new release, you reach for Pigsty, and it is already there. That is the standard a distribution should aspire to.

So the theme of v4.1 is not “more features.” It is about turning fast, reliable delivery into a repeatable capability – not a one-time heroic sprint, but a steady engineering discipline.

Not Just PostgreSQL: OS Minors Move Together

Being fast is one thing; being fast and correct is another. This round covers more than PostgreSQL minor upgrades – we also advanced the Linux distro minor baselines:

• EL: 9.6/10.0 -> 9.7/10.1
• Debian: 12.12/13.1 -> 12.13/13.3

We prepared offline packages for the latest minor versions across 14 mainstream Linux distros.

One important note to keep in mind:

Offline packages for EL 9.7 / 10.1 are NOT compatible with EL 9.6 / 10.0.

Many users deploy in intranet or fully air-gapped environments. If package versions do not match, online installation is the safe fallback.

Pig Agent-Native CLI: Letting The Tool Speak for Itself

Here is a practical example: imagine asking Claude Code to install PostgreSQL 18 plus extensions on three machines. When it calls pig, you do not need to craft prompts explaining how pig works – pig can describe itself to the agent directly. That is the idea behind Agent-Native design.

Traditional CLI tools are built for a human sitting at a terminal: colored output, formatted tables, progress bars. All great for people, but not ideal for agents. What agents really need are three things:

• What the tool can do: capabilities described explicitly, rather than requiring the agent to guess or parse documentation.
• What it did: execution results returned as structured JSON/YAML, not free-form text that requires regex parsing.
• What context it sees: environment information that is programmatically discoverable and transferable.

These principles sound straightforward, but applying them properly meant revisiting every subcommand. In pig 1.1.0, JSON/YAML output is no longer an afterthought; it is a first-class interface so that every operation can be invoked and parsed reliably by machines.

In the spirit of transparency: I proposed the concept and participated in design reviews, but the bulk of the implementation was carried out with the help of Codex and Claude Code. I handled the final review and acceptance. This is also Pigsty’s first truly AI-native project.

AI Coding: Less About Writing Code, More About Sweeping Blind Spots

During v4.1, I spent a good deal of time on pig and pg_exporter, leaning heavily on AI coding tools for review – mainly Claude Code and Codex 5.3 Extra High.

The real value is not that “AI is magical.” It is something more mundane but genuinely useful: blind-spot sweeping.

In mature systems, the most dangerous bugs are rarely obvious logic failures. The tricky ones are details that look fine, run fine, and only break at specific boundaries. For example, a metric unit that differs between PG17 and PG18, or an io_method version guard written as >= 17 when it should be >= 18.

We all miss things like these – our eyes tend to glide over code that “looks right.” AI tooling is surprisingly good at catching them. It will methodically work through every line, especially when given targeted prompts like “verify version guards.”

In this cycle, that kind of sweep surfaced and fixed roughly 10 to 20 additional issues. Each one is small on its own, but the cumulative effect is something users can feel.

A special thank you to community contributor @l2dy for many thoughtful issues that helped us close a batch of dashboard and config edge cases. This is how open-source quality compounds – through people who care about the details.

Firewall Defaults: One Extra Command Is Better Than a Silent Risk

A small but important change: in v4.0, the default firewall mode was set to none, meaning “do not touch your firewall.” The intention was reasonable, but user feedback made it clear this was not the right call.

EL9 enables firewalld by default, and many users are not fully aware of their current firewall state. When Pigsty takes the hands-off approach, users tend to assume everything is fine – only to discover later that intra-network traffic is blocked, spending hours debugging mismatched rules. That experience is worse than a bit of upfront configuration.

So in v4.1, the default returns to zone, with a straightforward policy:

• Trust private network CIDRs by default.
• On public networks, open only 22 (SSH), 80 (HTTP), and 443 (HTTPS).
• Database port 5432 is no longer exposed publicly by default.

If you need public database access, you can add it explicitly. It may mean one extra command in some cases, but when it comes to security defaults, we believe a conservative approach is the safer choice.

Seven New Extensions, Now 451 in Total

Every release brings updates to the extension ecosystem. This time we added 7, bringing total support to 451. A few highlights:

• pg_track_optimizer 0.9.1: automatic index tracking and optimization recommendations.
• nominatim_fdw 1.1.0: OpenStreetMap geocoding FDW, useful for GIS workloads.
• pg_utl_smtp 1.0.0: send email directly from PostgreSQL, familiar to Oracle migration users.
• pg_strict 1.0.2: strict mode guardrails to avoid unqualified UPDATE/DELETE.

Meanwhile, TimescaleDB moved to 2.25.0, Citus 14.0.0 landed, and Postgres Anonymizer reached 3.0 – all meaningful updates in their respective domains.

Other Notable Changes

Here are a few more changes worth highlighting:

• Autovacuum thresholds tuned: raised autovacuum_vacuum_threshold from 50 to 500 and analyze_threshold from 50 to 250 in oltp/crit/tiny. This reduces noisy vacuum/analyze churn for many small tables (common in multi-tenant systems).
• FD limit chain unified: fixed hierarchy between fs.nr_open and LimitNOFILE, unified at 8M to avoid high-concurrency FD exhaustion caused by inconsistent kernel/systemd settings.
• checkpoint_completion_target: increased from 0.90 to 0.95 for smoother IO distribution and less checkpoint jitter.
• Vibe defaults adjusted: Jupyter is now off by default (since most users do not need it), and Claude Code is managed consistently via npm packages.
• infra-rm refactor: uninstall flow now includes segmented deregister cleanup instead of one-shot removal, so cleanup scope and order are easier to control.
• New Mattermost app template: one-click deployment with database, storage, and reverse proxy wiring.

Closing

v4.1 is not a big-bang release. There is no architecture rewrite, no dramatic new module. But it demonstrates something we think matters: day-zero production-grade support is not a lucky sprint – it can be a repeatable engineering capability.

Earlier I mentioned that users need confidence. That kind of trust is not built in a single moment. It is earned with every minor release, every security patch, every time you show up on schedule. v4.1 is one more step in that direction. Below are the full commit notes and technical details.

v4.1.0 Commit Note

curl https://pigsty.io/get | bash -s v4.1.0

72 commits, 252 files changed, +5,744 / -5,015 lines (v4.0.0..v4.1.0, 2026-02-02 ~ 2026-02-13)

Highlights

• Added 7 new extensions, total support reaches 451.
• pig moved to an Agent-Native CLI (1.0.0 -> 1.1.0) with explicit context and JSON/YAML outputs.
• Unified PostgreSQL/OS major/minor upgrade workflows.
• pg_exporter upgraded to v1.2.0 (1.1.2 -> 1.2.0) with PG17/18 metric and unit fixes.
• Default firewall policy tightened: node_firewall_mode=zone, node_firewall_public_port=[22,80,443].
• PostgreSQL minor updates: 18.2, 17.8, 16.12, 15.16, 14.21.
• Default EL minors bumped to 9.7 / 10.1, Debian minors to 12.13 / 13.3.
• New one-click Mattermost app template with optional PGFS/JuiceFS.
• Refactored infra-rm with segmented deregister cleanup.
• Tuned autovacuum defaults and NOFILE chain consistency.

Version Updates

• Pigsty: v4.0.0 -> v4.1.0
• pig CLI: 1.0.0 -> 1.1.0
• pg_exporter: 1.1.2 -> 1.2.0
• Default EL minors: 9.6/10.0 -> 9.7/10.1
• Default Debian minors: 12.12/13.1 -> 12.13/13.3

Extension Updates

• RPM Changelog 2026-02-12
• DEB Changelog 2026-02-12
• timescaledb 2.24.0 -> 2.25.0
• pg_search 0.21.4 -> 0.21.7
• pgmq 1.9.0 -> 1.10.0
• pg_textsearch 0.4.0 -> 0.5.0
• pljs 1.0.4 -> 1.0.5
• pg_track_optimizer 0.9.1 (new)
• nominatim_fdw 1.1.0 (new)
• pg_utl_smtp 1.0.0 (new)
• pg_strict 1.0.2 (new)
• pgmb 1.0.0 (new)
• pg_pwhash (new support)
• informix_fdw (new support)

API Changes

• Corrected io_method / io_workers template guard from pg_version >= 17 to pg_version >= 18.
• Fixed PG18 guards for idle_replication_slot_timeout / initdb --no-data-checksums.
• Broadened maintenance_io_concurrency effective range to PG13+.
• Raised autovacuum thresholds for oltp/crit/tiny/olap profiles.
• Increased default checkpoint_completion_target from 0.90 to 0.95.
• Added fs.nr_open: 8388608 into defaults and aligned NOFILE chain.
• Changed firewall defaults: node_firewall_mode=zone, public ports [22,80,443].
• Added validation support for pg_databases[*].parameters and pg_hba_rules[*].order.
• Added segmented tags in infra-rm.yml: deregister, config, env.
• Updated VIBE defaults and npm package set.
• PgBouncer alias cleanup: pool_size_reserve -> pool_reserve, pool_max_db_conn -> pool_connlimit.

Compatibility Fixes (Grouped)

• Redis replicaof guard and systemd stop behavior.
• pg_migration identifier qualification, quoting, and logging safety.
• pgsql role handler restart target and variable usage fixes.
• blackbox cleanup naming and pgAdmin pgpass format fix.
• Non-blocking pg_exporter startup.
• VIP parsing simplification (default mask 24).
• MinIO health-check retry bump (3 -> 5).
• Hostname setup switched to Ansible hostname module.
• .env normalization to KEY=VALUE in selected app templates.
• pg_crontab syntax fix in pigsty.yml.
• ETCD TLS/mTLS docs clarification.
• repo-add, Debian CN mirror compatibility, and Python 3 compatibility fixes.
• redis-exporter credential permission hardening.
• Sensitive credential logs masked in pgsql-user.yml.
• pg_monitor Victoria registration gate fixes.
• Cluster-scoped backup cleanup in pg_remove.

Selected Commits

7410de401 v4.1.0 release
fa31213ce conf(node): default firewall to zone with single-node 5432 override
bb8382c58 update default extension list to 451
770d01959 hide user credential in pgsql-user playbook
7219a896c pg_monitor: fix victoria registration gate conditions
7005617f1 pgsql: drop legacy pgbouncer pool parameter aliases
74c59aabe grafana: fix dashboard links, descriptions, and overrides
36c95c749 fix(cli): restore repo-add execution and HBA validation failure propagation
6f2576fd0 fix(node): set default fs.nr_open via node_sysctl_params
26e108788 fix(monitor): correct unit for time metrics scaled by pg_exporter
d439464b2 pgsql: fix pg_version guards for PG18-only settings
cb52375ac bump checkpoint_completion_target from 0.90 to 0.95
c402f0e6d fix: correct io_method/io_workers version guard from PG17 to PG18
3bf676546 vibe: disable jupyter by default and install claude-code via npm_packages
613c4efa9 fix: set fs.nr_open in tuned profiles and reduce LimitNOFILE to 8M
4cc68ed61 refine infra removal playbook
318d85e6e simplify VIP parsing and make pg_exporter non-blocking
4bff01100 fix redis replicaof guard and systemd stop
38445b68d minio: increase health check retries
a237e6c99 tune autovacuum threshold to reduce small table vacuum frequency

For the full 72-commit list, see the GitHub release page.

Thanks

• Thanks to @l2dy for valuable suggestions and issues.

Checksums

8bc75e8df0e3830931f2ddab71b89630  pigsty-v4.1.0.tgz
da10de99d819421630f430d01bc9de62  pigsty-pkg-v4.1.0.d12.aarch64.tgz
e1f2ed2da0d6b8c360f9fa2faaa7e175  pigsty-pkg-v4.1.0.d12.x86_64.tgz
382bb38a81c138b1b3e7c194211c2138  pigsty-pkg-v4.1.0.d13.aarch64.tgz
13ceaa728901cc4202687f03d25f1479  pigsty-pkg-v4.1.0.d13.x86_64.tgz
92d061de4d495d05d42f91e4283e7502  pigsty-pkg-v4.1.0.el10.aarch64.tgz
be629ea91adf86bbd7e1c59b659d0069  pigsty-pkg-v4.1.0.el10.x86_64.tgz
c14be706119ba33dd06c71dda6c02298  pigsty-pkg-v4.1.0.el8.aarch64.tgz
0c8b6952ffc00e3b169896129ea39184  pigsty-pkg-v4.1.0.el8.x86_64.tgz
cfcc63b9ecc525165674f58f9365aa19  pigsty-pkg-v4.1.0.el9.aarch64.tgz
34f733080bfa9c8515d1573c35f3e870  pigsty-pkg-v4.1.0.el9.x86_64.tgz
ad52ce9bf25e4d834e55873b3f9ada51  pigsty-pkg-v4.1.0.u22.aarch64.tgz
300b2185c61a03ea7733248e526f3342  pigsty-pkg-v4.1.0.u22.x86_64.tgz
2e561e6ae9abb14796872059d2f694a8  pigsty-pkg-v4.1.0.u24.aarch64.tgz
c462bb4cb2359e771ffcad006888fbd4  pigsty-pkg-v4.1.0.u24.x86_64.tgz

1.12 - The Agent Moat: Runtime

Originally published on VONNG.

3 AM. Database alerts are blowing up.

You throw the alert info at a “top-tier” DBA Agent. It’s well-read — knows the PostgreSQL docs inside out, writes beautiful diagnostic SQL, can recite every kernel parameter from memory. It freezes: What’s the cluster topology? Where are the primary and replicas? How do I check the dashboards? Where are the logs? How was the last similar incident resolved? What tool do I use to do what?

It knows nothing.

Meanwhile, the agent next door — running a mediocre model but deeply wired into the full ops environment — has already identified the root cause, completed the failover, and filed the post-mortem.

The principle is simple: a mediocre local who knows the terrain beats a genius dropped into unfamiliar territory. That’s home court advantage. Intelligence without context is idle. An agent without a runtime is vapor.

OtterTune: A $12M Lesson

In 2020, CMU’s database rockstar professor Andy Pavlo and his students founded OtterTune — AI-powered database auto-tuning. Top-tier academic team, $12M in funding, targeting PostgreSQL and MySQL. Impressive pedigree.

The product pitch boiled down to: give me a connection string, and AI will tune your database.

In June 2024, OtterTune shut down. The stated reason was a failed acquisition. But in my view, the real problem was: what you can do with a connection string just isn’t worth much.

Through a connection string, you can see slow queries in pg_stat_statements, config parameters in pg_settings, stats from a few system views. Then what? Twiddle a few knobs, optimize a few queries. That’s it.

But real database operations go far beyond this. A connection string connects to one PostgreSQL instance, but in the real world you’re dealing with clusters — primaries, replicas, offline standbys, sync backups. Above clusters, there’s horizontal sharding. At the top level, hundreds of clusters belonging to different business units. Beyond the database itself, you need backup status, HA component health, connection pool metrics, host CPU/memory/disk/network metrics. All of this lives outside the connection string.

An agent with only a connection string is like someone trying to understand a room by peeking through the keyhole — extremely limited visibility. Worse: the things you can do through a connection string are exactly what a raw LLM already handles well. Ask Claude or GPT to look at a slow query and it gives solid optimization advice. If an LLM can do what you do out of the box, where’s your moat?

OtterTune’s fundamental mistake was a runtime problem: it tried to do ops without an operational environment. Optimizing an abstract, bare PostgreSQL — it had a powerful brain but no hands, no eyes, no body. Like asking Stephen Hawking to do gymnastics.

PS: I know they’ve started a second venture, again doing PostgreSQL tuning. Hope they get it right this time.

Manus: The Real Core Is the Sandbox

If OtterTune is the cautionary tale, Manus is the success story.

In March 2025, Manus appeared out of nowhere and became an instant phenomenon. Many people studied why it succeeded, focusing on its accumulated Markdown prompts or which LLM it uses.

Wrong target.

Manus’s real core isn’t the prompts or the model. It’s the VM sandbox — every user session runs in an isolated cloud Linux VM with a full filesystem, browser, shell, and code interpreter. The agent works inside this deterministic environment: reading/writing files, executing code, browsing the web, deploying apps.

Manus themselves said it clearly: “The power of Sandbox lies in its completeness.”

It’s this complete, deterministic sandbox that unleashes the model’s full capability. Without the sandbox, the same model is just a chatbot. With it, it becomes an agent that actually gets things done. And Manus has swapped underlying models multiple times — GPT to Claude — performance stayed solid throughout.

The recent viral hit OpenClaw proves the same point. It earned the “AI with hands” label not because the underlying model is superior, but because it deeply integrates with the host OS — filesystem, shell, browser, calendar, messaging apps all wired through CLI. Drop it into a blank cloud VM, stripped of those local hooks, and it’s just another chatbot.

Manus and OpenClaw validate the same thing: the LLM is the brain, but what really matters is the body.

Brain, Body, and Determinism

Let’s push the Manus insight one level deeper.

Biologically, intelligence requires three components: sensors (perceive the environment), decision-makers (process information), actuators (act on the environment). A creature with a brain but no body isn’t an intelligent agent — it’s a brain in a vat.

Agents are the same. The LLM is the decision-maker, but you also need sensors and actuators — i.e., observability and controllability. Together, these form the agent’s body. And for this body to function, there’s a prerequisite: determinism.

You can’t drop a brain into an unfamiliar environment and have it operate a weirdly-shaped robotic arm. The brain must “know” its body — which signals produce which actions, which feedback means which state. Brain and body need a stable, predictable protocol between them.

That’s the essence of a runtime: the agent’s deterministic body.

For a DBA Agent, a complete runtime means:

Sensors — full-stack observability. Not just what a connection string can see, but host metrics, connection pool stats, HA component heartbeats, backup progress, and internal database statistics — all organically fused, providing layered visibility from single instances to the entire data platform.

Actuators — full-stack controllability. Config changes, HA failover, backup/restore, rolling upgrades. Not calling someone else’s API, but directly shaping the infrastructure. If you’re just wrapping cloud vendor APIs, your agent is forever capped by the original author’s imagination.

Determinism — predictable behavior and auditable records. Same operation, same conditions, same result. Every step logged, every change reversible. Non-deterministic environments can’t produce deterministic outcomes.

Five years ago, when I started building PostgreSQL monitoring, I hit this exact problem: if you want the best monitoring system, you can’t rely on just a connection string. A connection string gets you something, but “something” is miles from “good.” To push observability to the limit, you must control the runtime — directly shape the infrastructure. That’s the pivotal moment that evolved Pigsty from a PostgreSQL monitoring project into a full-blown PostgreSQL distribution. What’s true for monitoring is true for management, and even more so for intelligence.

OtterTune had a brain but no body. The outcome was predetermined. Manus built a deterministic body (sandbox), and the brain’s power was finally unleashed.

A DBA Agent’s Body: Only Three Options

Let’s use a concrete scenario — the DBA Agent. A coding agent’s context is a code directory. What’s a DBA agent’s context?

What is a DBA agent’s body? Who can provide it?

Option 1: Cloud vendors. RDS, Cloud SQL, Azure Database — monitoring, alerting, backup, HA, all included. But it’s someone else’s body. Your agent can only move within the vendor’s sandbox. Ops knowledge accumulates on the vendor platform, locked in. Switch clouds and it’s back to zero. If you’re building an agent on top of cloud APIs like OtterTune did, your design ceiling is the cloud API’s ceiling. This isn’t a body — it’s a cage.

Option 2: Kubernetes. K8s Operators can theoretically provide automated ops capability. But K8s introduces massive unnecessary complexity for databases — storage orchestration, network policies, stateful management, CRD abstraction layers upon layers. An agent doing database ops on K8s needs to grok an order of magnitude more concepts than just managing the database directly. K8s abstraction layers create enormous impedance, pushing the agent further from what it actually manages — the database itself. This isn’t providing a body — it’s strapping on a bulky spacesuit.

Option 3: Pigsty. An open-source PostgreSQL distribution that provides a full-stack deterministic runtime directly on bare Linux. Complete observability covering host-to-database monitoring, production-grade HA with automated backup/restore, 444 extensions out of the box, entire infrastructure managed as IaC.

The difference between Pigsty and cloud database runtimes: it’s an open-source, free body that belongs to you. Every layer of the runtime is open — agents can directly read metrics, query logs, invoke standard ops interfaces. No black boxes. No walled gardens. Ops knowledge accumulates on your own infrastructure. Runs on any cloud, or from your laptop to your data center.

The difference between Pigsty and K8s: no unnecessary abstraction layers. The agent faces the database and OS directly. Short operation paths. High determinism. To use an analogy: cloud vendors are a rented theater — well-equipped but full of rules, expensive, and you can’t take the set pieces when you leave. K8s is an over-engineered theater where it takes three days just to learn how to turn on the lights. Pigsty is your own theater — well-equipped, clean layout, actors perform freely, and everything you build belongs to you.

Someone’s Already On Stage

The Tsinghua University database team started working on this in 2024. Their D-Bot project explores autonomous fault diagnosis, root cause analysis, and repair recommendations in a complete Pigsty ops environment. The choice itself is telling: not poking at a remote connection string, but working inside a full runtime with monitoring, tooling, a knowledge base, and operational interfaces.

I contributed to this VLDB paper: D-Bot: Database Diagnosis System using Large Language Models

Academic research needs reproducible environments, and Infrastructure as Code naturally delivers this. Same config deployed a hundred times, identical environment every time. That’s exactly the determinism agents need. Meanwhile, I’m building a DBA Agent myself. Who understands a runtime better than the person who built it? On an open runtime, academic teams explore boundaries, infrastructure builders refine the core, community developers contribute ideas. An ecosystem is forming.

If you’re interested in DBA agents, Pigsty might be the best proving ground. It provides everything a PostgreSQL service needs in a real enterprise environment — full HA with PITR, and best-of-breed observability.

Dragons Come and Go, Territory Stays

Back to 3 AM.

Same alert, but this time the agent runs on a complete runtime — inside its own body. It sees the anomaly curve on the monitoring dashboard, pinpoints the root cause from logs, confirms cluster topology and primary/replica status, completes the failover via standard procedure, verifies post-failover health, and generates a post-mortem report. Fully automated. Fully auditable.

The model might be GPT, Claude, or some open-source model — doesn’t matter. The agent itself might just be a few simple Skills and a CLAUDE.md file — also doesn’t matter. The moat in the agent era isn’t a smarter brain; it’s a more deterministic body. Inside this deterministic body, a simple CLAUDE.md file is enough to make a mid-tier LLM perform at a mid-level DBA’s competence.

OtterTune spent $12M proving: a brain without a body doesn’t work. Manus proved with a sandbox: give the brain a deterministic body, and it creates miracles. Dragons arrive one after another, each stronger than the last. But the local who’s been cultivating home turf for years keeps building deeper moats.

Dragons come and go. Territory stays. That’s the real moat of the agent era.

1.13 - Pigsty v4.0: Into the AI Era

Originally published on VONNG.

Pigsty v4.0 is here! This is a milestone release.

Pigsty is a batteries-included, open-source, local-first PostgreSQL distribution. It lets you spin up enterprise-grade PostgreSQL services without a dedicated DBA — monitoring, backup, HA, IaC, connection pooling, and 444 extensions out of the box.

v4.0 is a major architectural overhaul: 320 commits, ~400k lines changed (though 300k+ of that is monitoring dashboards). I’d call this version “Finished Software” — it’s reached a state I’m genuinely satisfied with.

v4.0 theme: More Open, More Efficient, More Secure, More Intelligent. Let’s dive in.

TL;DR

• License: Back to Apache 2.0
• Infra Overhaul: Victoria Stack FTW
• Container Support: Docker Gang Rejoice
• PG 18 Ready: 444 Extensions Standing By
• Security Hardening: Passwords, Firewall, SELinux
• JUICE Module: Database as Filesystem
• VIBE Module: Claude Code Runtime
• DBA Agent: Skills & CLI
• HA Optimization: RTO/RPO Deep Dive
• Instant Clone: Fork DBs & Instances in Milliseconds
• IaC Enhancements: More Fine-Grained Knobs
• Vibe Coding IRL: 90% AI-Written Code
• Finished Software: Quality I’m Happy With
• Entering the AI Era: Built for Agents

License Change: Back to Apache 2.0

Pigsty v4.0 switches from AGPLv3 back to the permissive Apache 2.0 license. For enterprise users, no more legal battles. ISVs can integrate freely. Want to build your own custom PG distro? Fork Pigsty and skip the yak shaving.

For the full rationale, see my separate post: From AGPL to Apache: Thoughts on Pigsty’s Relicensing.

Observability Overhaul: Victoria Stack FTW

The flagship change in v4: replacing Prometheus and Loki with the Victoria Stack, plus adding tracing.

VictoriaMetrics is the chad replacement for Prometheus. We ran it at scale at Tantan years ago — stunning results, fraction of the resources, multiple times the performance.

The trigger this time was Loki’s lackluster performance, and Promtail (its log collector) getting deprecated this year. I went with the current SOTA: VictoriaLogs + Vector, and threw in VMetrics + VTrace for good measure.

Results speak for themselves: querying a day’s worth of logs used to show a loading spinner; now VictoriaLogs returns instantly. We migrated all log collection to VictoriaLogs, designed a Prometheus-consistent label schema, and added log monitoring for every component. Each component now has Logs & Panels, plus brand new dashboards for Node Vector, Node Juice, and Claude Code.

Architecture got simpler too: previously different components needed different Nginx endpoints. Now everything mounts on a single Nginx server. No more juggling domains and ports — one domain (or just IP) gives you Grafana, logs, metrics, and Alertmanager. Enterprise edition even auto-localizes to Chinese with translated metric titles, descriptions, and usage notes.

Big picture: the current INFRA module is basically a Victoria distro — Metrics + Logs + Trace + Alert + unified UI. Add the OOTB Grafana and you’ve got an enterprise-grade observability platform.

Container Support: Docker Gang Rejoice

Docker support was the most requested feature — running Pigsty itself in containers. Previously doable but required manual param tweaking and systemd kung-fu. Now we ship official base images. Got Docker? One command and you’re up! (Assuming your Docker Hub access is… sorted.)

cd ~/pigsty/docker; make launch  # One-click single-node containerized Pigsty

I wrestled with the image design: ship everything pre-installed, or a minimal deployable image? Went with the latter — based on Debian 13 official image, added systemd, ssh, sudo, and pigsty itself. Everything else happens during deploy phase. Base image is ~200 MB (vs 3 GB for the kitchen sink).

Post-deploy, you’re good to go: port 8080 for web, 2222 for ssh, 5432 for postgres. Works on Windows, macOS, Linux — quick and easy test drive.

PG 18 Ready: 444 Extensions Standing By

A core v4 goal: make PostgreSQL 18 production-ready as the default version. This release cycle, we added PG 18 support for major extensions: TimescaleDB, ParadeDB, Citus, DocumentDB, AGE.

To make this happen, we compiled ~226+ extension packages for 6 PG major versions across 14 Linux distros, bringing total available extensions to 444. Also fixed numerous missing extension combos in PGDG. Plus 10 brand new extensions:

We also overhauled default PG param configs. Users can now configure the new io_method to leverage async I/O, and file_copy_method = clone is enabled for “instant database cloning” support. Every PG 17/18 param (and legacy ones) got a thorough review with updated best-practice defaults.

Oracle-compatible IvorySQL kernel and TDE-encrypted Percona kernel both ship with PG 18 support. MongoDB-compatible FerretDB (after switching to Microsoft’s DocumentDB version) also supports PG 18.

Bottom line: PG 18’s major extensions are locked and loaded, params fully optimized, metrics fully collected. PG 18 in Pigsty is battle-ready for the harshest production environments.

Security Hardening: Passwords, Firewall, SELinux

v4 went hard on security, checking boxes against compliance standards like China’s MLPS and SOC2. Highlights:

Random strong default passwords: Users kept deploying with default creds. Now configure -g auto-replaces all default passwords with random strong ones.

ETCD RBAC enabled: Previously global cert auth. Now each PG cluster gets its own etcd user/password. Admin nodes manage all clusters; regular DB nodes only manage their own cluster. No more cross-cluster interference.

SELinux rules optimized: Previously disabled by default. Now EL systems have proper security contexts configured, default permissive mode, enforce when ready.

Firewall support by default: Define public-facing ports and internal subnets. Even without cloud security groups, you can minimize exposure yourself (default: ssh 22, http 80, https 443, optionally pgsql 5432).

We also audited all user/file permission models, consolidated data under a unified directory (/data) for easy Docker mounts, split permissions by user groups, strict least-privilege principle.

These security policies are progressive: with random strong passwords generated, default config is already secure enough. Advanced options are there for enterprises to evaluate tradeoffs.

JUICE Module: Database as Filesystem

v4’s new JUICE module integrates JuiceFS, mounting object storage and PostgreSQL as a local filesystem. The killer feature: store both data and metadata in the same PG instance for consistent PITR of filesystem and database. Details in PGFS: Database as Filesystem.

This solves a real pain point: apps with both filesystem (knowledge base files) and database. DB PITR is easy; filesystem PITR is hard; keeping both consistent is a nightmare. Now you can store files in the database and get synchronized point-in-time rollback for the entire system.

This capability is clutch for Agents. Vibe Code on a mounted directory, all changes stored in the database in real-time. Unlike Git’s manual snapshots, you can instantly rollback to any historical point. Previously only high-end commercial CDP appliances had this — now Pigsty provides it free. PIGLET AI sandbox has this configured by default.

VIBE Module: Claude Code Runtime

The VIBE module is for Vibe Coding — completely optional. Ships with Node.js, Claude Code, VS Code and Jupyter accessible from browser. Also uv python package manager, npm, golang, hugo, and other essential tools. China deployments auto-configure Python/Node mirror sources — fast installs, no GFW wrestling.

Best part: turnkey Claude Code environment, one command downloads and configures the latest version. One line of config to use CC + domestic GLM 4.7, various convenience shortcuts, Claude Code can YOLO in Sandbox mode. Includes a Grafana Dashboard for monitoring Claude Code — real-time visibility into what your Agent is doing and thinking. Even ships happy + tmux so you can voice-command CC from your phone.

VIBE module pairs with JUICE module — that’s exactly how PIGLET.RUN sandbox works: mount your code directory to the database via JuiceFS, leverage DB’s PITR capability to one-click rollback both filesystem and database to any point in time.

This module powers PIGLET.RUN and is the cloud dev environment I personally use. Post-install, you’ve got a complete cloud development environment — secure and fully equipped.

DBA Agent: Skills & CLI

VIBE isn’t just for coding. Its real purpose: foundation for the DBA Agent I’m building — install Claude Code with this module, and it can already do valuable work in a Pigsty environment. Database health checks, reports, query optimization — no sweat.

I previously wrote a PostgreSQL quick-start tutorial: install Pigsty, run Open Code calling GLM-4 model, let it play teacher. User feedback was wild. Some DBAs tried it and said “this thing is scary” — throw a health check task at it, zero extra config, performs remarkably well.

Of course, letting Agents go full YOLO in prod is too aggressive. Hard rules still need careful config: absolute no-go operations, mandatory human confirmation, permission boundaries. We’ve got a basic CLAUDE.md in the pigsty home directory telling CC what’s allowed and what’s not. Launch from that directory to enable it.

Pigsty has a unique advantage for DBA Agents: highly deterministic context and environment, clearly described and managed in code. From day one, Pigsty committed to IaC (Infrastructure as Code) + CLI — GUI only for monitoring, never for control.

Because we believe the endgame for programmatic, intelligent management is IaC + CLI. CC just needs to read pigsty.yml to understand what modules and components exist in your environment, how to access and use them.

A simple, AgentNative CLI is a force multiplier for both DBAs and DBA Agents. The pig v1.0 shipping with Pigsty v4 provides exactly this — wrapping complex commands and operation sequences into idiot-proof / Agent-friendly commands. More posts coming on this.

HA Optimization: RTO/RPO Deep Dive

Beyond AI4PG and PG4AI, v4 also levels up on core database service fundamentals. Detailed breakdown in PostgreSQL HA: The State of the Art.

Pigsty users have diverse scenarios: same-rack deployment, cross-DC disaster recovery, cross-continent architectures (200ms+ latency, high packet loss). These scenarios have completely different HA param requirements.

Previously we shared one tuned Patroni param set. Now we provide four pre-baked param templates for different scenarios.

Similarly, following Oracle’s data protection modes, we offer three typical RPO templates for users to trade off data consistency against performance/availability.

Interestingly, when we deep-dived this topic, we found most Patroni-based HA solutions in the wild use default params — no one had systematically analyzed RTO composition. So I did quantitative analysis of RTO breakdown across failure paths, ensuring these param sets keep worst-case RTO under specified bounds. Theoretical analysis so users can run Patroni HA with peace of mind.

Theoretical decomposition keeps RTO upper bounds at 30/45/90/150s for the four param sets

Instant Clone: Fork DBs & Instances in Milliseconds

HA isn’t the only improvement — PITR got significant upgrades too. See Git for Data: Instant Clone PG Databases. PostgreSQL 18 brings instant cloning — exactly what AI apps need: fast, cheap clones.

Prod databases can be hundreds of GB or even TB — you can’t test directly on them. Fork uses COW (Copy-on-Write), even massive databases clone in ~200ms. Coolest part: storage stays flat — two 100GB databases still only use 100GB total.

pg-meta:
  hosts:
    10.10.10.10: { pg_seq: 1, pg_role: primary }
  vars:
    pg_cluster: pg-meta
    pg_version: 18
    pg_databases:
      - { name: meta }                                           # source database
      - { name: meta_dev ,template: meta , strategy: FILE_COPY}  # bin/pgsql-db meta_dev

With XFS filesystem (mainstream Linux default), you get instance-level instant cloning too: fork a large instance instantly, zero extra storage, zero prod impact. Combined with classic cluster PITR, you can rapidly clone PostgreSQL at instance, database, and cluster levels, and rollback to any point within retention period.

To further lower the PITR barrier, we baked PITR into the pig CLI: run pig pitr, it handles everything automagically. Restore your database cluster in-place/incrementally/efficiently to your target point. Newbies and AI Agents alike can leverage this easily — that’s the bar we’re aiming for.

IaC Enhancements: More Fine-Grained Knobs

Previously Pigsty didn’t support deleting users or databases — delete ops are dangerous, involving complex SOPs for cleaning up dependent objects and permissions. But users genuinely needed this: complex resource configs got messy, wanted to nuke and restart. We implemented drop database and drop user. Don’t underestimate this — seemingly simple, actually very hard to do right: almost all cloud RDS services only support dropping “naked users”, any dependencies and the system just errors out.

v4 also revamped the IaC API design, adding and aligning params through PG 18. For example, user-level customization for the three role inheritance options: ADMIN, INHERIT, SET. You can specify extra Locale params for databases, use state for deleting or rebuilding databases/users, and manage Schemas and Extensions within databases.

HBA rule definitions now support an order field — explicitly specify priority order for each rule. Internal subnet definitions are also customizable now, consistent with default firewall policies. PG gets its own dedicated crontab list, separate from system-wide scheduled tasks.

Countless other refinements: injection protection on virtually all param slots, special handling for PG’s list params, etc. — won’t belabor the details. End result: IaC your way to customizing every PostgreSQL cluster detail. Databases, users, inheritance, permissions, HBA, services, extensions, schemas — one shot, spin up production-ready database clusters. This IaC config-as-code approach is natural and friendly for both DBAs and DBA Agents.

Vibe Coding IRL: Taste & Validation Are the Moat

Let’s talk engineering practice: 90%+ of Pigsty v4.0 code was written by Claude Code. I only handled three things: propose ideas, design APIs, validate results. Methodology in four phases:

Design: Play PM, discuss and generate design docs with AI. CC’s API design taste isn’t quite there yet — this part I do myself.

Implement: New session, have AI implement code. After completion, 10 rounds of self-reflection and revision, giving review feedback each round until satisfied.

Review: Another session, have AI run automated tests in VM sandbox.

Validate: Final manual testing.

Claude Code is like a brilliant but slightly domain-inexperienced genius intern. If your instincts are right and direction is correct, it nails the details. This senior-junior pair programming is highly efficient — I typically run three User Stories in parallel. CC codes blazingly fast; the bottleneck is me.

Usually after locking design, CC’s first-attempt success rate hits 90%+. The remaining 10% needs multiple iterations. Especially for domains like RDS with virtually no public documentation — requires tons of manual guidance to reach final satisfaction.

Two things Claude Code still struggles with: first, API design — still needs taste to gatekeep, CC only offers ideas and suggestions; second, validation efficiency — current bottleneck is manual validation speed (blocked on me) because smoke test SOPs are slow.

This gave me an insight: In the Agent coding era, design taste and validation capability are the real moats. Even with code open-sourced, most people lack both secondary development ability and QA capability — that’s the actual barrier. Code is getting “cheap,” but “getting the right thing right” remains expensive.

This reminds me of SQLite’s model: source code is public domain, but the core test suite TH3 is proprietary. With AI assistants, a super-individual can match a full team; external contributions actually slow things down. So Pigsty will take a similar path: Open Source, but not Open Collaboration — accepting Issues, feature requests, and feedback only, no more PRs.

Finished Software: Quality I’m Happy With

As mentioned in From AGPL to Apache: Thoughts on Pigsty’s Relicensing, I’d give v4.0 a solid 90/100. SOTA AI’s assessment is basically the same: on PostgreSQL service quality, free Pigsty already beats top-tier cloud RDS, reaching pinnacle level among open-source solutions.

So I figure it’s about there — that’s why I called v4.0 “Finished Software” at the top.

But “finished” isn’t “archived.” In software lifecycle terms, Finished means it’s good enough, stable enough, trustworthy enough for production. Like a quality blade — the edge is honed, now comes long-term use, maintenance, passing down. I’ll keep maintaining Pigsty — bug fixes, version tracking, extension packaging. With AI help, this barely takes time; one PG major version per year is fine. The remaining 10 points are left for ecosystem, product, and commercial services to grow.

And my energy can finally shift to that seed planted three years ago.

Entering the AI Era: Built for Agents

Three years ago, I wrote Database Needs Pyramid, listing Intelligent Autonomous Database as the ultimate goal. Back then it was just a vision. Today, it’s becoming real.

From day one, Pigsty committed to IaC + CLI, keeping GUI only for observation, not control. Many didn’t get it: why not build a pretty console?

Now the answer is clear — because we were waiting for Agents.

Agents don’t need to click buttons. They need to read configs, call APIs, execute commands. Pigsty’s architecture is native to programmatic management. While others are still figuring out how to make AI operate GUIs, Pigsty users can already have Claude Code directly read pigsty.yml, understand the entire infrastructure, and get to work.

This is what “entering the AI era” really means: not bolting AI features onto software, but making software a native habitat for AI.

For this, I’ve prepared two wings:

PIG — Originally just a package manager, repositioned in v1.0 as PostgreSQL ecosystem’s Agent Native CLI. Full lifecycle management of databases, connection pools, HA, backup, and access. It’s the Agent’s hands for operating PostgreSQL.

PIGLET.RUN — A PostgreSQL-centric Agent runtime. Lightweight Pigsty sub-distro where users just talk and generate complete, database-backed complex applications. It’s the soil where Agents thrive.

And Pigsty itself aims to be the infrastructure foundation that keeps you deterministic in the AI era — bold enough to let Agents go hands-free, confident enough to one-click rollback to yesterday when they screw up.

Describe it with IaC, understand it with observability, constrain it with permissions, correct it with PITR. This isn’t “yet another PostgreSQL install script” — it’s a complete engineering methodology for keeping complex systems in a cage.

Data is the lifeblood of systems. Databases are the hearts guarding that lifeblood.

Agents are becoming a new form of life. They think, they act, they err, they learn.

And every life needs a reliable heart.

Pigsty v4.0, built for this era.

Welcome to the game.

Pigsty v4.0.0 ReleaseNote

Quick Start

curl https://pigsty.io/get | bash -s v4.0.0

318 commits, 604 files changed, +118,655 / -327,552 lines

Release Date: 2025-12-25 | GitHub | Docs EN | Docs CN

Highlights

• Observability Revolution: Prometheus → VictoriaMetrics (10x perf), Loki+Promtail → VictoriaLogs+Vector
• Security Hardening: Auto-generated passwords, etcd RBAC, firewall/SELinux modes, permission tightening, Nginx Basic Auth
• Docker Support: Run Pigsty in Docker containers with full systemd support
• New Module: JUICE - Mount PostgreSQL as filesystem with PITR recovery
• New Module: VIBE - AI coding sandbox with Claude Code, JupyterLab, VS Code Server
• Database Management: pg_databases state, instant clone with strategy
• PITR & Fork: /pg/bin/pg-fork for instant CoW cloning, enhanced pg-pitr
• HA Enhancement: pg_rto_plan with 4 RTO presets, pg_crontab scheduled tasks
• Multi-Cloud Terraform: AWS, Azure, GCP, Hetzner, DigitalOcean, Linode, Vultr, TencentCloud
• License Change: AGPL-3.0 → Apache-2.0

Infrastructure Package Updates

MinIO now uses pgsty/minio fork RPM/DEB.

Docker Support

Pigsty now supports running in Docker containers with full systemd support, working on both macOS (Docker Desktop) and Linux.

Quick Start:

cd ~/pigsty/docker; make launch    # = make up config deploy

New Modules

v4.0.0 adds two optional modules that don’t affect core Pigsty functionality:

JUICE Module: JuiceFS Distributed Filesystem

• Uses PostgreSQL as metadata engine, supports PITR recovery for filesystem
• Multiple storage backends: PostgreSQL large objects, MinIO, S3
• Multi-instance deployment with Prometheus metrics per instance
• New node-juice dashboard for JuiceFS monitoring
• New juice.yml playbook for deployment
• Parameters: juice_cache, juice_instances

VIBE Module: AI Coding Sandbox (Code-Server + JupyterLab + Node.js + Claude Code)

• Code-Server: VS Code in browser

  • Deploy Code-Server with Nginx reverse proxy for HTTPS
  • Supports Open VSX and Microsoft extension galleries
  • Set code_enabled: false to disable
  • Parameters: code_enabled, code_port, code_data, code_password, code_gallery

• JupyterLab: Interactive computing environment

  • Deploy JupyterLab with Nginx reverse proxy for HTTPS
  • Python venv configuration for data science libraries
  • Set jupyter_enabled: false to disable
  • Parameters: jupyter_enabled, jupyter_port, jupyter_data, jupyter_password, jupyter_venv

• Node.js: JavaScript runtime environment

  • Install Node.js with npm package manager
  • Auto-configure China npm mirror when region=china
  • Set nodejs_enabled: false to disable
  • Parameters: nodejs_enabled, nodejs_registry

• Claude Code: AI coding assistant CLI configuration

  • Configure Claude Code CLI, skip onboarding
  • Built-in OpenTelemetry config sending metrics/logs to Victoria stack
  • New claude-code dashboard for usage monitoring
  • Set claude_enabled: false to disable
  • Parameters: claude_enabled, claude_env

• New vibe.yml playbook for full VIBE deployment

• Use conf/vibe.yml template for quick AI coding sandbox setup

• Common parameter: vibe_data (default /fs) for workspace directory

PostgreSQL Extension Updates

Major extensions add PG 18 support: age, citus, documentdb, pg_search, timescaledb, pg_bulkload, rum, etc.

New Extensions:

• pg_textsearch 0.4.0 - TimescaleDB full-text search
• pg_clickhouse 0.1.3 - ClickHouse FDW
• pg_ai_query 0.1.1 - AI query extension
• etcd_fdw 0.0.0 - etcd FDW
• pg_ttl_index 0.1.0 - TTL index
• pljs 1.0.4 - JavaScript procedural language
• pg_retry 1.0.0 - Retry extension
• pg_weighted_statistics 1.0.0 - Weighted statistics
• pg_enigma 0.5.0 - Encryption extension
• pglinter 1.0.1 - SQL Linter
• documentdb_extended_rum 0.109 - DocumentDB RUM
• mobilitydb_datagen 1.3.0 - MobilityDB data generator

Major Updates:

pgBackRest updated to 2.58 with HTTP support.

Observability

• VictoriaMetrics replaces Prometheus — several times the performance
• VictoriaLogs + Vector replaces Promtail + Loki for log collection
• Unified log format for all components, PG logs use UTC timestamp
• PostgreSQL log rotation changed to weekly truncated rotation mode
• Recording temp file allocations over 1MB in PG logs
• Added Vector parsing configs for Nginx/Syslog/PG CSV/Pgbackrest/Grafana/Redis/etcd/MinIO
• Datasource registration runs on all Infra nodes, auto-registered in Grafana
• New grafana_pgurl parameter for using PG as Grafana backend storage
• New grafana_view_password parameter for Grafana Meta datasource password
• pgbackrest_exporter default cache interval reduced from 600s to 120s
• grafana_clean default changed from true to false
• New pg_timeline collector for real-time timeline metrics
• New pg:ixact_ratio metric for idle transaction ratio monitoring
• pg_exporter updated to 1.1.2 with pg_timeline collector
• Added slot name coalesce for pg_recv metrics collector
• Blackbox ping monitoring support enabled
• New node-vector dashboard for Vector monitoring
• New node-juice dashboard for JuiceFS monitoring
• New claude-code dashboard for Claude Code usage monitoring
• PGSQL Cluster/Instance dashboards add version banner
• All dashboards use compact JSON format, reducing file size

Interface Improvements

Playbook Rename:

• install.yml → deploy.yml for better semantics
• New vibe.yml playbook for VIBE AI coding sandbox

pg_databases Improvements:

• Database removal: use state field (create, absent, recreate)
• Database cloning: use strategy parameter for clone method
• Support newer locale params: locale_provider, icu_locale, icu_rules
• Support is_template to mark template databases
• Added type checks to prevent character parameter injection
• Allow state: absent in extension to remove extensions

pg_users Improvements:

• New admin parameter with ADMIN OPTION for re-granting
• New set and inherit options for user role attributes

pg_hba Improvements:

• Support order field for HBA rule priority
• Support IPv6 localhost access
• Allow specifying trusted intranet via node_firewall_intranet

Other Improvements:

• Default privileges for Supabase roles
• node_crontab auto-restores original crontab on node-rm
• New infra_extra_services for homepage service entries

Parameter Optimization

I/O Parameters

• pg_io_method: auto, sync, worker, io_uring options, default worker
• maintenance_io_concurrency set to 100 for SSD
• effective_io_concurrency reduced from 1000 to 200
• file_copy_method set to clone for PG18 instant database cloning

Replication & Logging

• idle_replication_slot_timeout: default 7d, crit template 3d
• log_lock_failures: enabled for oltp, crit templates
• track_cost_delay_timing: enabled for olap, crit templates
• log_connections: auth logs for oltp/olap, full logs for crit

HA Parameters

• New pg_rto_plan integrating Patroni & HAProxy RTO config
  • fast: Fastest failover (~15s), for high availability requirements
  • norm: Standard mode (~30s), balanced (default)
  • safe: Safe mode (~60s), reduced false positives
  • wide: Relaxed mode (~120s), for geo-distributed deployments
• pg_crontab: scheduled tasks for postgres dbsu
• For PG17+, explicitly disable checksums if pg_checksums is off
• Crit template enables Patroni strict sync mode

Backup & Recovery

• PITR default archive_mode changed to preserve
• pg-pitr supports pre-recovery backup

Other

• Fixed duckdb.allow_community_extensions always active issue
• pg_hba and pgbouncer_hba now support IPv6 localhost

Architecture Improvements

Directories & Portal:

• Fixed /infra symlink pointing to /data/infra on Infra nodes
• Infra data defaults to /data/infra for container convenience
• Local repo at /data/nginx/pigsty, /www symlinks to /data/nginx
• DNS records moved to /infra/hosts, solving Ansible SELinux race
• Default homepage domain renamed from h.pigsty to i.pigsty

Scripts:

• New /pg/bin/pg-fork for instant CoW replica creation
• Enhanced /pg/bin/pg-pitr for instance-level PITR with pre-backup
• New /pg/bin/pg-drop-role for safe user deletion
• New bin/pgsql-ext for extension installation
• Restored pg-vacuum and pg-repack scripts

New Playbooks:

• juice.yml: Deploy JuiceFS instances
• vibe.yml: Deploy VIBE AI sandbox

Module Improvements:

• Explicit cron/cronie package installation for minimal system
• UV Python manager moved from infra to node module
• pg_remove/pg_pitr etcd metadata removal runs on etcd cluster
• Simu template simplified from 36 to 20 nodes
• Removed PGDG sysupdate repo and llvmjit packages on EL systems
• Using full OS version for EPEL 10 / PGDG 9/10 repos
• Allow meta parameter in repo definitions
• Vagrant libvirt templates default to 128GB disk with xfs
• Ensure pgbouncer doesn’t modify 0.0.0.0 to *
• New 10-node and Citus Vagrant templates
• Restored EL7 compatibility

System Tuning:

• Tuned systemd service NOFILE limits based on workload
• Fixed tuned profile activation by restarting tuned service
• Added runtime directory for PostgreSQL systemd service
• Fixed ip_local_port_range start/end value parity alignment

Multi-Cloud:

• Terraform: AWS, Azure, GCP, Hetzner, DigitalOcean, Linode, Vultr, TencentCloud

Security Improvements

Password Management:

• configure -g for auto-generating strong random passwords
• Changed MinIO default password to avoid well-known defaults

Firewall & SELinux:

• Replaced node_disable_firewall with node_firewall_mode
• Replaced node_disable_selinux with node_selinux_mode
• Configured correct SELinux contexts for HAProxy, Nginx, DNSMasq, Redis

Access Control:

• Enabled etcd RBAC, each cluster can only manage its own PG cluster
• etcd root password stored in /etc/etcd/etcd.pass, admin-readable only
• Added admin_ip to Patroni API whitelist
• Always create admin system group, patronictl restricted to admin group
• New node_admin_sudo parameter for admin sudo mode
• Revoked script ownership from non-root users

Certificates & Auth:

• Nginx Basic Auth support for optional HTTP authentication
• Fixed ownca certificate validity for Chrome recognition
• New vip_auth_pass parameter for VRRP authentication

Other:

• Fixed ansible copy content empty field errors
• Fixed pg_pitr race conditions during Patroni cluster recovery
• Protected files/pki/ca directory with mode 0700

Bug Fixes

Parameter Changes

New Parameters

Removed Parameters

Default Value Changes

Compatibility

PostgreSQL: 13, 14, 15, 16, 17, 18

Checksums

9f42b8c64180491b59bd03016c26e8ca  pigsty-v4.0.0.tgz
db9797c3c8ae21320b76a442c1135c7b  pigsty-pkg-v4.0.0.d12.aarch64.tgz
1eed26eee42066ca71b9aecbf2ca1237  pigsty-pkg-v4.0.0.d12.x86_64.tgz
03540e41f575d6c3a7c63d1d30276d49  pigsty-pkg-v4.0.0.d13.aarch64.tgz
36a6ee284c0dd6d9f7d823c44280b88f  pigsty-pkg-v4.0.0.d13.x86_64.tgz
f2b6ec49d02916944b74014505d05258  pigsty-pkg-v4.0.0.el10.aarch64.tgz
73f64c349366fe23c022f81fe305d6da  pigsty-pkg-v4.0.0.el10.x86_64.tgz
287f767fbb66a9aaca9f0f22e4f20491  pigsty-pkg-v4.0.0.el8.aarch64.tgz
c0886aab454bd86245f3869ef2ab4451  pigsty-pkg-v4.0.0.el8.x86_64.tgz
094ab31bcf4a3cedbd8091bc0f3ba44c  pigsty-pkg-v4.0.0.el9.aarch64.tgz
235ccba44891b6474a76a81750712544  pigsty-pkg-v4.0.0.el9.x86_64.tgz
f2791c96db4cc17a8a4008fc8d9ad310  pigsty-pkg-v4.0.0.u22.aarch64.tgz
3099c4453eef03b766d68e04b8d5e483  pigsty-pkg-v4.0.0.u22.x86_64.tgz
49a93c2158434f1adf0d9f5bcbbb1ca5  pigsty-pkg-v4.0.0.u24.aarch64.tgz
4acaa5aeb39c6e4e23d781d37318d49b  pigsty-pkg-v4.0.0.u24.x86_64.tgz

1.14 - From AGPL to Apache: Why I Changed Pigsty's License

Originally published on VONNG.

Pigsty is a batteries-included, local-first PostgreSQL distribution. With the v4.0 release, I finally did something I’d been considering for a while: switching from AGPLv3 back to Apache 2.0.

Here’s why I changed it, what it means, and my take on open source, ecosystems, and commercialization.

The Origin Story

Pigsty started with Apache 2.0.

The reasoning was simple: I built something useful, open-sourced it so others could benefit, and hoped to push PostgreSQL practices forward. Apache felt natural — permissive, no strings attached.

Then came v2.0, and I switched to AGPLv3. The surface reason: some well-known projects had moved to AGPL, and I thought Pigsty might have “caught” their license through dependency. After more research, I realized that wasn’t actually true — I wasn’t linking to them as libraries.

The real reason: I’d started a company. Commercial responsibility meant thinking about protecting commercial interests. So I picked one of the most restrictive open-source licenses available.

We added explicit disclaimers: we wouldn’t pursue regular users; enforcement would effectively match Apache 2.0; AGPL was just “keeping our options open against extreme cloud vendor freeloading.”

In practice? That option delivered none of the protection I wanted — only adoption friction.

Fast forward to today: the company has been wound down, and I’m back to being a solo developer again. Ironically, with steady consulting revenue, I can now afford to treat Pigsty as what it started as — a public good.

AGPL in Practice

The first problem is straightforward: AGPL triggers immediate legal red flags at most companies. Default policy is “don’t touch” — unclear risk, slow approvals, high compliance cost.

You can explain “we won’t pursue regular users” or “it doesn’t propagate in this case.” Often doesn’t matter. Policy is policy.

I’ve had this conversation with engineers at multiple large tech companies. The pattern is consistent: I’d suggest self-hosting Postgres with Pigsty. Response? “We’d love to evaluate it, but AGPL is a non-starter. Legal won’t even look at it.”

After enough of these conversations, you realize: AGPL creates adoption barriers — not technical ones, but process barriers. And process barriers are often harder to break through than technical ones.

The second problem: AGPL may not actually prevent the freeloading you’re worried about.

Real example: a solutions architect at a major cloud vendor deploys Pigsty on cloud infrastructure for their customer. Issues come up, they pay me for support. The vendor delivered successfully using Pigsty.

Legally? AGPL has limited teeth here. This consulting/professional-services model doesn’t trigger AGPL’s network clause — the code isn’t offered as SaaS. It’s not the scenario AGPL was designed for.

In practice, AGPL often scares away legitimate users without blocking the scenarios you actually worried about. The data backs this up: after switching to AGPL, Pigsty’s adoption growth visibly slowed — exponential became linear.

Martin Kleppmann (author of DDIA) made a similar point years ago: GPL/AGPL don’t solve cloud-era value distribution. If you want to restrict cloud vendors, you need source-available licenses (ELv2, SSPL, BSL) or product strategy (local-first, ecosystem lock-in) — not GPL hoping to deliver justice.

AGPL ended up being neither open-source-friendly enough nor effective against cloud. Worst of both worlds.

Why Not ELv2 / SSPL / BSL?

Natural follow-up: if AGPL doesn’t work, why not ELv2? It’s basically Apache for normal users but explicitly restricts cloud vendors.

I considered it seriously. Pigsty is approaching “finished software” status — I don’t need PRs, and with tools like Claude, I can ship features fast. Community value for me isn’t code contributions; it’s:

• Real-world feedback and edge case discovery
• Reusable templates and best practices
• Case studies, word-of-mouth, ecosystem connections

So: do I actually need an OSI-approved license?

In the end, I didn’t go with ELv2. One reason: that’s not what I want to build.

I want Pigsty to become the Debian of databases.

Debian didn’t win by restricting users. It won through openness, reusability, distributability — eventually becoming the default upstream, the standard, the infrastructure.

The Debian of Databases

As I discussed in “Forging a PostgreSQL Distribution”: Pigsty’s goal is to become the Debian of the PostgreSQL world — globally useful, freely distributable, endlessly customizable.

My read: the next two years are a window of significant change. AI, agents, infrastructure shifts — these will reshuffle who becomes the default choice.

PostgreSQL is already the Linux kernel of databases. The distribution wars are just beginning. These windows don’t open often. Pigsty has a seat at the table, and I’m not sitting this one out.

To win this, you don’t wield licenses as weapons. You win by:

• Keeping users happy and productive
• Letting vendors integrate and redistribute
• Giving ISVs paths to profit
• Creating value for DEV, OPS, and DBA

For this to work, a permissive license is almost mandatory. It signals intent: welcome to use, integrate, distribute, fork.

Put bluntly: freeloaders welcome.

One line I do draw: ship it, sell it, build on it — all fine. Just don’t claim you wrote it from scratch.

On Freeloading

People ask: everyone’s moving toward source-available and restrictive licenses. Why go back to Apache? Aren’t you worried about freeloading?

My view is simple: if you’re worried about freeloading and want to monetize via licensing, don’t open-source — sell commercial software. If you choose true open source, accept the reality: it will be used, integrated, redistributed. Treat it as a gift. As Linus put it — Just for Fun.

Sure, I’m not thrilled when cloud vendors rebrand open-source projects to upsell compute. But that playbook doesn’t work well on Pigsty — it’s not a library they can wrap. It is the database platform, competing directly with their managed offerings.

Major cloud vendors already have their own managed Postgres, deeply integrated with their infrastructure. Rebranding Pigsty as their RDS would mean competing with themselves.

When I say “get off the cloud,” I mean managed database PaaS. Self-hosting on cloud VMs is fine. IaaS works — the main issue is EBS-style network storage being mediocre for databases. NVMe instance storage exists; use it if it fits.

For vendors who want to offer self-hosted Postgres deployment as a service: you’re welcome here. Growing the ecosystem beats playing license cop.

From Distribution to Meta-Distribution

A permissive license also enables Pigsty’s evolution from “a PG distribution” to a meta-distribution.

From day one, Pigsty was designed to be fully customizable. It provides a complete toolbox plus the largest binary extension repository in the PostgreSQL ecosystem. You can build your own distribution on top — like how countless Linux variants grew from Debian and Red Hat.

Example: PIGLET.RUN, a project I’m working on, adds a vibe-coding toolbox to Pigsty’s single-node template — spin up Claude Code, VS Code, and full-stack services with one click. That’s a first-party Pigsty sub-distribution.

You can swap kernels — use your own Postgres fork. If you’ve built extensions or tools, package them in. For PG kernel vendors, this is compelling: a bare RPM becomes “HA, backup, monitoring, IaC, offline delivery” out of the box. Order-of-magnitude value increase.

We’ve supported custom kernels since v3. Spin up Supabase, OrioleDB, PolarDB, IvorySQL, or others with one click. Each could be its own sub-distribution.

For meta-distribution to work, the license must be permissive. Otherwise you’re saying “welcome to distribute” while writing “distribution triggers obligations.” Ecosystems don’t grow that way.

Long-term, I’d like Pigsty to develop proper governance — maybe even a committee structure like Debian. Ambitious, but that’s what makes it interesting.

Timing: Finished Software

Why switch at v4.0? Because v4.0 is a milestone — it’s reached “finished software” status.

I ran comparative evaluations against major cloud database offerings. Short version: we’re playing in the same league. Except we’re free.

RDS PG Evaluation: Claude | ChatGPT

That’s roughly where I want it to stay. Push too far past parity and you cannibalize your own consulting business — I’m selling the delta from “works great” to “bulletproof in production.”

ISVs and independent DBAs building commercial services on Pigsty: welcome. The market is massive. You serve your customers, I provide upstream support. Handle what you can, escalate when you can’t. That’s how ecosystems work.

Business Model

People often ask, How do you make money with it?

The model I admire: VictoriaMetrics. One developer built a monitoring system that dominates on performance in the observability area. Started a company for enterprise support, kept some modules enterprise-only. No fundraising, no pressure, sustainable. Pigsty follows a similar path.

Pigsty has a commercial edition — same codebase, but supports more operating systems and legacy PG versions. Includes CLI tooling, DBA agent, SOPs, and a non-open-source test suite with failure scenarios — similar to SQLite’s approach.

But the commercial edition isn’t the point. Enterprises don’t pay for what you’ve open-sourced — they pay for delivered value: taking production from “works well” to “bulletproof” That includes warranties, SLAs, troubleshooting, and operational know-how from running Postgres at scale — things that won’t appear in AI training dataset. So I’m not selling the product — that’s free. Pigsty is free; while the consulting isn’t.

AI Agent has been a force multiplier. Most of my time now goes to asking the right questions and validating outputs. Scales quiet well.

If you’re using Pigsty and find value in what I’m building, subscriptions are welcome. You get commercial guarantees; I get to keep building.

On Relicensing: Doing It Right

Relicensing deserves its own discussion.

My view: permissive-to-restrictive is ethically problematic — textbook bait-and-switch. Contributors signed up under one set of expectations; you’re retroactively changing the deal.

Restrictive-to-permissive is fundamentally different. You’re giving more freedom to everyone, including past contributors.

That said, I wanted to do this cleanly. I reached out to contributors for explicit consent. Not everyone responded — and I won’t assume consent. So I rewrote all code from non-responding contributors. In a ~150k lines codebase, this was roughly 500 lines, not much.

Was this strictly necessary? Legally, probably not — going permissive doesn’t require unanimous consent like going restrictive would. But I’d rather over-comply than leave gray areas. Practice what you preach.

Conclusion

Going from AGPL to Apache 2.0 isn’t going soft. It’s not naive.

It’s strategic: Pigsty aims to be the Debian of databases. Openness and inclusivity aren’t slogans — they’re engineering requirements. Reduce friction, expand distribution, build ecosystem.

Pigsty v4.0 is out. I hope it helps more people to enjoy PostgreSQL

1.15 - Pigsty v3.7: Magneto Award and PG18 Ready

Originally published on VONNG.

GitHub Release | Release Note

Pigsty v3.7.0 is officially released, bringing complete production-grade PostgreSQL 18 support and support for four new operating systems: Debian 13 and EL 10 across both x86_64/ARM64 architectures. Extension count has grown from 423 to 437, with numerous extensions updated to latest versions.

Additionally, Supabase, IvorySQL, PolarDB, Percona TDE, and other kernels have all been upgraded to latest versions, and infrastructure components like Prometheus, Grafana, DuckDB, and Etcd have completed a round of concentrated updates.

For outstanding contributions to the PostgreSQL extension ecosystem, Pigsty received the “PostgreSQL Magneto” award at the 8th PostgreSQL Database Ecosystem Conference.

PostgreSQL 18 Becomes Default Version

With the release of PostgreSQL 18.1, PG 18 is production-ready. Pigsty v3.7 officially sets it as the default version.

PG 18 introduces several important features: Temporal Primary Key, built-in UUIDv7, Index Skip Scan, Asynchronous I/O (AIO), virtual generated columns, EXPLAIN enhancements, OAuth 2.0 support, and more. If these features match your business needs, now is a good time to upgrade.

Meanwhile, PG 13.23 released in November will be the last PG 13 version — that major version has officially entered EOL status. Pigsty v3.7 is the last version with complete PG 13 extension support — all extensions have been recompiled, but will no longer be updated going forward.

Epic Extension Update

Supporting PG 18 goes far beyond kernel deployment. From the beta stage, Pigsty has provided PG 18 deployment capability, but to make it the production default, extension ecosystem follow-through is crucial. Currently, except for Citus, mainstream extensions all support PG 18. We’ve fixed dozens of extension compatibility issues and unified pgrx versions across 40+ Rust extensions.

This is an epic update. Available extensions on PG 18 reach 390-405 (varies slightly by distribution). Complete extension availability information is available at PGEXT.CLOUD. Extension updates over the past three months:

Several extensions see milestone updates:

• pg_duckdb 1.1: Code quality significantly improved, EL8 compatibility issues fixed
• pg_mooncake 0.2: Rewritten in Rust, now a sub-extension of pg_duckdb, both can coexist
• VectorChord 1.0: Official stable version released
• pg_search 0.20: Major ParadeDB full-text search extension update

Supporting PG 18, Debian 13, and EL 10 means the compile/test matrix expanded from 50 combinations (5 PG × 10 OS) to 84 combinations (6 PG × 14 OS) — a 68% increase. RPM/DEB packages in the repository grew from 40,000+ to 60,000+.

To improve efficiency, we fully automated the entire extension build process. Now just spin up a container, execute pig build pkg <ext> to complete the build. This extension repository and build infrastructure is completely standalone — even without using Pigsty, you can install extensions directly via YUM/APT. All code is Apache-2.0 licensed open source.

For this contribution, Pigsty received the “PostgreSQL Magneto” award at the 8th PostgreSQL Database Ecosystem Conference.

New OS Support: EL 10 and Debian 13

This version adds four new OS support targets, bringing the mainstream support total to 14.

Major challenges during adaptation:

• EL 10 Missing Ansible: Official repos lack ansible-collection-community-crypto — we ported and packaged the EL9 version
• Ansible 2.19 Breaking Changes: Extensive syntax incompatibilities required comprehensive adaptation to ensure both old and new versions work correctly
• LLVM Version Upgrade: PGDG repos on EL9/EL10 upgraded from LLVM 19 to LLVM 20, introducing compatibility issues
• ARM64 Repository Adjustments: el10.aarch64 PGDG repos underwent multiple rounds of adjustment
• Frequent Dependency Changes: Upstream package dependencies continuously shifting

This is also why we don’t recommend users manually wrestling with PostgreSQL deployment: often the problem isn’t operator error but upstream changes causing dependency breakage. Using Pigsty offline packages locks in complete dependencies at a specific point in time, ensuring deployment stability.

Maintenance Strategy Adjustment: Pigsty will only maintain the two most recent major versions in each series. With EL 10 and Debian 13 joining, EL 8, Debian 11, and Ubuntu 20.04 will no longer receive proactive updates (support not removed) — new extension packages and test processes will no longer cover these older systems.

Multi-Kernel Synchronized Updates

Besides the vanilla PostgreSQL kernel, this version synchronizes updates across multiple derivative kernels:

All these kernels work smoothly on new operating systems (except Babelfish), further solidifying Pigsty’s position as a “Meta-Distribution” — a unified platform for out-of-the-box experience with various PostgreSQL flavors.

Parameter Template Optimization

Default parameter templates optimized for PG 18 and new scenarios:

• Optimized CPU, process, thread, and parallel query related parameter configurations
• Ensured adequate background worker resources for various extensions
• Relaxed OLTP template restrictions on parallel queries
• Added maintenance, troubleshooting, and accidental deletion recovery SOP documentation

Vision: The Ubuntu of the PostgreSQL Ecosystem

Pigsty has become the highest-starred PostgreSQL ecosystem open-source project from China, establishing considerable recognition and influence internationally.

Our vision: Make Pigsty the mainstream distribution in the PostgreSQL world, occupying an ecosystem position in the database realm similar to Debian, Ubuntu, and RHEL in the operating system realm.

Implementation path:

• Focus on Core Scenarios: Large-scale production-grade PostgreSQL management on native Linux
• Build Differentiated Advantages: Industry-leading monitoring system and most complete extension ecosystem
• Integrate Ecosystem Resources: Incorporating core capabilities from distributions like Supabase and Percona
• Optimize Developer Experience: Balancing professionalism with usability

v3.7.0

Pigsty v3.7.0 released with deep PostgreSQL 18 support!

curl https://repo.pigsty.cc/get | bash -s v3.7.0

Highlights

• Deep PostgreSQL 18 support, becomes default PG major version, extensions ready!
• Added EL10 / Debian 13 OS support, total reaches 14!
• Added PostgreSQL extensions, total reaches 437!
• Supports Ansible 2.19 post-breaking-change versions!
• Supabase, PolarDB, IvorySQL, Percona kernels updated to latest versions!
• Optimized PG default parameter setting logic for better resource utilization.

Version Updates

• PostgreSQL 18.1, 17.7, 16.11, 15.15, 14.20, 13.23
• Patroni 4.1.0
• Pgbouncer 1.25.0
• pg_exporter 1.0.3
• pgbackrest 2.57.0
• Supabase 2025-11
• PolarDB 15.15.5.0
• FerretDB 2.7.0
• DuckDB 1.4.2
• Etcd 3.6.6
• pig 0.7.4

For more software version updates, refer to:

• INFRA Changelog
• RPM Changelog
• DEB Changelog

API Changes

• Set more reasonable optimization strategies for parallel execution related parameters
• In rich and full templates, citus extension no longer installed by default because citus doesn’t yet support PG 18
• PG parameter templates now include duckdb series extension stubs
• Set 200, 2000, 3000 GB upper limits for min_wal_size, max_wal_size, max_slot_wal_keep_size
• Set 200 GB upper limit for temp_file_limit, 2 TB for OLAP
• Appropriately increased default connection pool connection counts
• Added prometheus_port parameter with default value 9058, avoiding conflict with EL10 RHEL Web Console port
• Changed alertmanager_port parameter default to 9059, avoiding potential conflict with Kafka SSL port
• Added pg_pkg pg_pre subtask to remove bpftool, python3-perf causing LLVM conflicts on el9+ before installing PG packages
• Added llvm repository module to Debian/Ubuntu default repository definitions
• Fixed infra-rm.yml package removal logic

Compatibility Fixes

• Fixed Ubuntu/Debian CA trust Warning return code error
• Fixed extensive compatibility issues introduced by Ansible 2.19, ensuring normal operation on old and new versions
• Added int type conversion for seq type variables to ensure compatibility
• Changed many with_items to loop syntax for compatibility
• Added a layer of list nesting for key exchange variables to avoid character iteration on strings in new versions
• Explicitly converted range usage to list before use
• Modified name, port and other reserved marker variable naming
• Changed play_hosts to ansible_play_hosts
• Added string forced type conversion for some string types to avoid runtime errors

EL10 Logic Adaptation

• Fixed EL10 missing ansible-collection-community-crypto unable to generate keys issue
• Fixed EL10 missing ansible logical package issue
• Removed modulemd_tools flamegraph timescaledb-tool
• Use java-21-openjdk instead of java-17-openjdk
• aarch64 YUM repository name issues

Debian 13 Logic Adaptation

• Use bind9-dnsutils instead of dnsutils

Ubuntu 24 Fixes

• Temporarily removed tcpdump package with broken upstream dependencies

Checksums

e00d0c2ac45e9eff1cc77927f9cd09df  pigsty-v3.7.0.tgz
987529769d85a3a01776caefefa93ecb  pigsty-pkg-v3.7.0.d12.aarch64.tgz
2d8272493784ae35abeac84568950623  pigsty-pkg-v3.7.0.d12.x86_64.tgz
090cc2531dcc25db3302f35cb3076dfa  pigsty-pkg-v3.7.0.d13.x86_64.tgz
ddc54a9c4a585da323c60736b8560f55  pigsty-pkg-v3.7.0.el10.aarch64.tgz
d376e75c490e8f326ea0f0fbb4a8fd9b  pigsty-pkg-v3.7.0.el10.x86_64.tgz
8c2deeba1e1d09ef3d46d77a99494e71  pigsty-pkg-v3.7.0.el8.aarch64.tgz
9795e059bd884b9d1b2208011abe43cd  pigsty-pkg-v3.7.0.el8.x86_64.tgz
08b860155d6764ae817ed25f2fcf9e5b  pigsty-pkg-v3.7.0.el9.aarch64.tgz
1ac430768e488a449d350ce245975baa  pigsty-pkg-v3.7.0.el9.x86_64.tgz
e033aaf23690755848db255904ab3bcd  pigsty-pkg-v3.7.0.u22.aarch64.tgz
cc022ea89181d89d271a9aaabca04165  pigsty-pkg-v3.7.0.u22.x86_64.tgz
0e978598796db3ce96caebd76c76e960  pigsty-pkg-v3.7.0.u24.aarch64.tgz
48223898ace8812cc4ea79cf3178476a  pigsty-pkg-v3.7.0.u24.x86_64.tgz

See GitHub Release for more details.

1.16 - Forging a China-Rooted, Global PostgreSQL Distro

Originally published on VONNG.

Hi, I’m Feng Ruohang, author of Pigsty and an independent open-source contributor. Let’s talk about how to build a PostgreSQL distribution that is rooted in China and useful to the whole world.

The question isn’t whether PG will win—it already has. The question is: What role do we play in that victory? Spectator or protagonist? Follower or leader?

Why now

PostgreSQL is the default database

Stack Overflow’s 2025 survey shows 58.2% of professional developers use PG—18.6 points ahead of MySQL, and the gap is widening. New SaaS, AI startups, even OpenAI default to PG. DB-Engines rankings and JetBrains surveys tell the same story.

Capital agrees: in 2025 Databricks bought Neon (~$1 B) and Snowflake bought Crunchy Data ($250 M). AWS Aurora DSQL, Azure HorizonDB, GCP AlloyDB—all PG. Technology won, money followed.

China is missing from the PG narrative

Despite hundreds of domestic “PG-derived” products, our presence in the global ecosystem is faint. Until recently there wasn’t a single Chinese committer on the PG core list. The most visible Chinese-led PG project by GitHub stars is… Pigsty, a one-man project. That’s both flattering and a little sad.

At PG conferences I’ve met only a handful of Chinese developers. We’re spectators at our own victory parade.

What must change

The kernel wars are over; the fight shifts to distributions. Whoever controls the distro controls the experience—like Ubuntu did for Linux. We need a PG “Ubuntu” built with China’s strengths but serving global developers, the way DeepSeek did in AI.

Pigsty as a case study

Pigsty started at Tantan (China’s #2 dating app). We were dealing with 2.5 M global QPS, PL/pgSQL-heavy business logic, hundreds of physical clusters. Off-the-shelf tooling couldn’t cope, so we built our own HA, backups, monitoring, IaC. China’s scale was the forge. If it survives Tantan, it’s overkill everywhere else.

But “rooted in China” isn’t enough; “facing the world” means becoming part of the global supply chain. That requires obsessing over developer experience, not just DBA comfort.

In 2023 Pigsty already did HA + backups + observability + bare-metal delivery. Yet something was missing—features. PG’s true power is extensions. MySQL spends years grafting on vectors; PG’s community ships pgvector and kneecaps an entire market in months.

So I built an extension repository. I waited for others to do it, nobody did, so I compiled them myself: first a dozen, then dozens, then hundreds. Today Pigsty provides 437 extensions across EL9/EL8/Debian/Ubuntu, more than the official PGDG repos. That makes Pigsty part of the upstream supply chain: when developers apt install an extension, they’re using binaries built in China yet serving users worldwide.

Vision

• Rooted in China: leverage our scale, scenarios, and demand to harden solutions under extreme stress.
• Facing the world: ship battle-tested, developer-friendly distros and extension repos that anyone can consume, just like they consume Debian packages.
• Play to our strengths: we may not have a kernel committer yet, but we can dominate tooling, packaging, automation, and integrations—the layers that actually reach users.

Pigsty isn’t the only answer, but it proves a point: a single Chinese engineer, working the right problem, can earn a seat at PostgreSQL’s global table. Imagine what we could do together.

1.17 - Pigsty v3.6: The Ultimate PostgreSQL Distribution

Originally published on VONNG.

GitHub Release | Release Note

Pigsty v3.6 is officially released. After two months of careful refinement, this will be the last major version before v4.0, featuring extensive refactoring and improvements that lay a solid foundation for building the ultimate all-in-one PostgreSQL distribution.

This version deeply optimizes and refactors deployment tasks for PostgreSQL, MinIO, and Etcd, adds Percona PG TDE kernel support with out-of-the-box transparent encryption functionality. Additionally, the Supabase self-hosting experience has been comprehensively optimized, destructive database operations have been completely removed from idempotent playbooks, and a new fully automated pgsql-pitr playbook enables one-click point-in-time recovery.

The installation process has been further simplified: from four steps to three steps (download, configure, install), now defaulting to online installation mode which skips local software repository construction.

New Kernel Support: Percona PG TDE

Percona’s pg_tde extension has finally reached 1.0 GA after years of development. Many “enterprise-grade” PostgreSQL distributions tout “transparent encryption” as a core selling point — pg_tde may be the first mature enough open-source transparent encryption extension, providing truly enterprise-grade transparent encryption for open-source PostgreSQL.

Currently, this extension requires running on a patched PostgreSQL kernel — Percona’s Postgres distribution. Pigsty added support immediately after the announcement — just two commands to enable and install, while enjoying Pigsty’s full RDS capabilities: monitoring, high availability, PITR, IaC, and more — identical to the vanilla PG kernel.

With this, the number of PostgreSQL kernels supported by Pigsty has reached 10.

Pigsty has become a distribution of PostgreSQL distributions — a “meta-distribution.” Various PostgreSQL fork kernels can be transformed into “enterprise-grade database services” with high availability, monitoring, IaC, and PITR capabilities under Pigsty’s umbrella.

Extension Ecosystem Continues to Strengthen

Besides the Percona transparent encryption kernel, OrioleDB also released 1.5 beta12 — Supabase’s CEO revealed it’s nearing official GA. Pigsty has immediately compiled the OrioleDB-patched version of PG and its extensions.

Another noteworthy extension is pgactive — an AWS-developed and open-sourced PG multi-active extension that claims to solve sub-second high availability failover. This extension depends on the missing pgfeutils and has compilation barriers — Pigsty provides out-of-the-box binary packages.

Available extensions have reached 423. PG18 beta2, OrioleDB, TimescaleDB, Citus, FerretDB & DocumentDB, DuckDB, Etcd, and more have completed routine version updates.

The extension catalog site has also been completely revamped using Next.js reconstruction, with significantly improved appearance. New address: https://pgext.cloud

Supabase Self-Hosting Experience Optimization

Pigsty v3.6 provides a smoother Supabase self-hosting experience and fixes several issues in Supabase’s official templates:

• logflare replication slot not advancing
• Massive error log printing
• Studio unable to view two Analytics logs

Production-grade Supabase self-hosting requires just a few commands:

Additionally, Pigsty now defaults to using Docker Registry mirror sites provided by 1Panel, significantly improving download speeds in mainland China.

Currently, Pigsty and StackGres are the only two open-source vendors providing Supabase self-hosting solutions: Pigsty delivers on bare Linux systems, StackGres delivers on Kubernetes.

PITR Recovery Enhancement

In previous versions, Pigsty provided the pg-pitr script for “semi-automatic” PITR recovery assistance. This version adds a fully automated pgsql-pitr playbook for one-click point-in-time recovery.

This playbook automatically performs the following operations:

• Pause high availability failover
• Shut down PostgreSQL
• Generate and execute pgbackrest PITR recovery command to specified target point
• Verify and restart PostgreSQL
• Re-enable high availability failover

Supports fast retry (in-place incremental) for precise recovery point targeting. Also adds a new use case: performing PITR recovery on newly started instances (or detached replicas) to avoid affecting existing business, then extracting data from the new instance for manual import.

ETCD Management Simplified

This version refactors the Etcd module, adding independent etcd-rm.yml playbook and scaling SOP scripts.

Previously, scaling etcd involved a series of complex command operations — now just a few simple commands:

bin/etcd-add              # Create etcd cluster, or refresh existing cluster state
bin/etcd-add 10.10.10.11  # Scale out etcd cluster, add a new member
bin/etcd-rm               # Remove entire etcd cluster
bin/etcd-rm 10.10.10.11   # Remove specified member from cluster

The etcd.yml playbook no longer cleans existing ETCD clusters — cleanup is now handled by dedicated roles and playbooks, making maintenance simpler and clearer.

MinIO Module Improvements

The MinIO module has been refactored with a new Plain HTTP mode and adjusted default bucket and user configuration.

Previous versions enabled HTTPS for MinIO by default (via locally CA-signed self-signed certificates), avoiding intranet traffic snooping but causing some hassles: clients outside the Pigsty management node (like containers) need to trust that CA to access MinIO.

This version adds a switch allowing MinIO to run in pure HTTP mode. Note: pgbackrest doesn’t accept HTTP-mode MinIO, so local MinIO storage for PG backups still requires HTTPS mode. HTTP mode is only suitable for pure external service scenarios.

Default bucket configuration has also been adjusted:

Dedicated users s3user_meta and s3user_data have been created for meta and data buckets, with same-named policies for each bucket. With this design, applications like Supabase and Dify can directly use these two buckets without manual creation.

Installation Process Simplified

Installation steps reduced from four to three:

The “bootstrap” step (extracting offline packages or configuring upstream repos to install Ansible) has been merged into the download script — running the install script automatically executes ./bootstrap.

curl -fsSL https://repo.pigsty.io/get | bash; cd ~/pigsty; ./configure; ./install.yml

Online Installation by Default

The default installation strategy has changed: instead of downloading locally first then installing, it now installs directly from upstream internet sources.

This change brings significant benefits:

• Fewer failure points: Many user-reported installation errors occurred during local repo download and Nginx service startup phases (like el9.aarch64 patroni-etcd installation failure due to PGDG configuration errors)
• Faster speed: Only downloads packages that actually need to be installed, rather than downloading everything at once
• Simpler configuration: No need to handle Nginx security policies and firewall configuration issues

A large proportion of users install Pigsty on single-node Linux and “don’t need” the multi-node consistency provided by local software repositories. Users who need local repos can re-enable via simple configuration (repo_enabled, node_repo_modules) or directly use the rich / full templates that enable local repos by default.

New Documentation Site

The new documentation site is now live: https://pigsty.io/docs/

This site is built with Next.js and Fumadocs modern frontend stack — thanks to Lantian You and Claude Code for the strong assist. The English version is mostly complete; Chinese version is under translation. Contributions via GitHub PR or Issues are welcome.

Other Improvements

• tuned module optimization: Optimized for modern hardware and NVMe disks, removed outdated configuration parameters, added NVMe/virtualized SSD scheduling/readahead parameter optimizations
• MCP Toolbox integration: Integrated Google’s newly released MCP Toolbox (database MCP toolbox), with preset template SQL solving some database security issues
• Configuration template adjustments: All configuration templates adjusted to single-node mode for quicker onboarding

Next Steps: v4.0 and DBA Agent

PostgreSQL 18 will be released in September — Pigsty plans to officially release v4.0 after PG 18’s release. Main improvement directions:

The main theme of v4.x will be DBA Agent. Pigsty already has the complete context needed for a DBA Agent — the core being this industry-leading PG monitoring system. Once the domain knowledge accumulated in documentation is rich enough, wrapping MCP around the Pig CLI tool will birth a capable fully self-driving database DBA Agent.

v3.6.0

Pigsty v3.6.0 released with new documentation site and PITR enhancement!

curl https://repo.pigsty.cc/get | bash -s v3.6.0

Highlights

• New documentation site: https://pigsty.io/docs/
• Added pgsql-pitr playbook and backup/recovery tutorials, improved PITR experience
• New kernel support: Percona PG TDE (PG17)
• Optimized Supabase self-hosting experience, updated to latest version, resolved series of official template issues
• Simplified installation steps, defaults to online installation, more efficient and simple, bootstrap process (installing ansible) embedded in install script

Design Improvements

• Improved Etcd module implementation, added independent etcd-rm.yml playbook and scaling SOP scripts
• Improved MinIO module implementation, supports HTTP mode, creates three buckets with different properties out-of-the-box
• Re-adjusted and organized all configuration templates for easier use
• Uses faster Docker Registry mirror sites for mainland China
• Optimized tuned OS parameter templates for modern hardware and NVMe disks
• Added pgactive extension for multi-master replication and sub-second failover
• Adjusted pg_fs_main / pg_fs_backup default values, simplified file directory structure design

Bug Fixes

• Fixed pgbouncer config file error by @housei-zzy
• Fixed OrioleDB issues on Debian platform
• Fixed tuned shm config parameter issues
• Offline packages directly use PGDG source, avoiding out-of-sync mirror sites
• Fixed IvorySQL libxcrypt dependency issues
• Replaced broken and slow EPEL repository sites
• Fixed haproxy_enabled flag functionality

Infrastructure Package Updates

New Victoria Metrics / Victoria Logs related packages:

• genai-toolbox 0.9.0 (new)
• victoriametrics 1.120.0 -> 1.121.0 (refactored)
• vmutils 1.121.0 (renamed victoria-metrics-utils)
• grafana-victoriametrics-ds 0.15.1 -> 0.17.0
• victorialogs 1.24.0 -> 1.25.1 (refactored)
• vslogcli 1.24.0 -> 1.25.1
• vlagent 1.25.1 (new)
• grafana-victorialogs-ds 0.16.3 -> 0.18.1
• prometheus 3.4.1 -> 3.5.0
• grafana 12.0.0 -> 12.0.2
• vector 0.47.0 -> 0.48.0
• grafana-infinity-ds 3.2.1 -> 3.3.0
• keepalived_exporter 1.7.0
• blackbox_exporter 0.26.0 -> 0.27.0
• redis_exporter 1.72.1 -> 1.77.0
• rclone 1.69.3 -> 1.70.3

Database Package Updates

• PostgreSQL 18 Beta2 update
• pg_exporter 1.0.1, updated to latest dependencies with Docker image
• pig 0.6.0, updated latest extensions and repo list, with pig install subcommand
• vip-manager 3.0.0 -> 4.0.0
• ferretdb 2.2.0 -> 2.3.1
• dblab 0.32.0 -> 0.33.0
• duckdb 1.3.1 -> 1.3.2
• etcd 3.6.1 -> 3.6.3
• ferretdb 2.2.0 -> 2.4.0
• juicefs 1.2.3 -> 1.3.0
• tigerbeetle 0.16.41 -> 0.16.50
• pev2 1.15.0 -> 1.16.0

PG Extension Package Updates

• OrioleDB 1.5 beta12
• OriolePG 17.11
• plv8 3.2.3 -> 3.2.4
• postgresql_anonymizer 2.1.1 -> 2.3.0
• pgvectorscale 0.7.1 -> 0.8.0
• wrappers 0.5.0 -> 0.5.3
• supautils 2.9.1 -> 2.10.0
• citus 13.0.3 -> 13.1.0
• timescaledb 2.20.0 -> 2.21.1
• vchord 0.3.0 -> 0.4.3
• pgactive 2.1.5 (new)
• documentdb 0.103.0 -> 0.105.0
• pg_search 0.17.0

API Changes

• pg_fs_backup: Renamed to pg_fs_backup, default value /data/backups.
• pg_rm_bkup: Renamed to pg_rm_backup, default value true.
• pg_fs_main: Default value now adjusted to /data/postgres.
• nginx_cert_validity: New parameter to control Nginx self-signed certificate validity period, default 397d.
• minio_buckets: Default value adjusted to create three buckets named pgsql, meta, data.
• minio_users: Removed dba user, added s3user_meta and s3user_data users corresponding to meta and data buckets.
• minio_https: New parameter allowing MinIO to use HTTP mode.
• minio_provision: New parameter allowing skipping MinIO provisioning phase (skip bucket and user creation).
• minio_safeguard: New parameter that aborts operation when executing minio-rm.yml if enabled.
• minio_rm_data: New parameter controlling whether to delete minio data directory when executing minio-rm.yml.
• minio_rm_pkg: New parameter controlling whether to uninstall minio package when executing minio-rm.yml.
• etcd_learner: New parameter allowing etcd to initialize as learner.
• etcd_rm_data: New parameter controlling whether to delete etcd data directory when executing etcd-rm.yml.
• etcd_rm_pkg: New parameter controlling whether to uninstall etcd package when executing etcd-rm.yml.

Checksums

df64ac0c2b5aab39dd29698a640daf2e  pigsty-v3.6.0.tgz
cea861e2b4ec7ff5318e1b3c30b470cb  pigsty-pkg-v3.6.0.d12.aarch64.tgz
2f253af87e19550057c0e7fca876d37c  pigsty-pkg-v3.6.0.d12.x86_64.tgz
0158145b9bbf0e4a120b8bfa8b44f857  pigsty-pkg-v3.6.0.el8.aarch64.tgz
07330d687d04d26e7d569c8755426c5a  pigsty-pkg-v3.6.0.el8.x86_64.tgz
311df5a342b39e3288ebb8d14d81e0d1  pigsty-pkg-v3.6.0.el9.aarch64.tgz
92aad54cc1822b06d3e04a870ae14e29  pigsty-pkg-v3.6.0.el9.x86_64.tgz
c4fadf1645c8bbe3e83d5a01497fa9ca  pigsty-pkg-v3.6.0.u22.aarch64.tgz
5477ed6be96f156a43acd740df8a9b9b  pigsty-pkg-v3.6.0.u22.x86_64.tgz
196169afc1be02f93fcc599d42d005ca  pigsty-pkg-v3.6.0.u24.aarch64.tgz
dbe5c1e8a242a62fe6f6e1f6e6b6c281  pigsty-pkg-v3.6.0.u24.x86_64.tgz

See GitHub Release for more details.

v3.6.1

Pigsty v3.6.1 released with PostgreSQL minor version updates!

curl https://repo.pigsty.cc/get | bash -s v3.6.1

Highlights

• PostgreSQL 17.6, 16.10, 15.14, 14.19, 13.22, and 18 Beta 3 support
• Using Pigsty-provided PGDG APT/YUM mirrors in mainland China to resolve update supply issues
• New website homepage: https://pigsty.io
• Added el10, debian 13 implementation stubs, and el10 Terraform images

Infrastructure Package Updates

• Grafana 12.1.0
• pg_exporter 1.0.2
• pig 0.6.1
• vector 0.49.0
• redis_exporter 1.75.0
• mongo_exporter 0.47.0
• victoriametrics 1.123.0
• victorialogs: 1.28.0
• grafana-victoriametrics-ds 0.18.3
• grafana-victorialogs-ds 0.19.3
• grafana-infinity-ds 3.4.1
• etcd 3.6.4
• ferretdb 2.5.0
• tigerbeetle 0.16.54
• genai-toolbox 0.12.0

Database Package Updates

• pg_search 0.17.3

API Changes

• Removed br_filter kernel module from node_kernel_modules default value.
• Uses OS major version number when adding PGDG YUM source, no longer uses minor version number.

Checksums

045977aff647acbfa77f0df32d863739  pigsty-pkg-v3.6.1.d12.aarch64.tgz
636b15c2d87830f2353680732e1af9d2  pigsty-pkg-v3.6.1.d12.x86_64.tgz
700a9f6d0db9c686d371bf1c05b54221  pigsty-pkg-v3.6.1.el8.aarch64.tgz
2aff03f911dd7be363ba38a392b71a16  pigsty-pkg-v3.6.1.el8.x86_64.tgz
ce07261b02b02b36a307dab83e460437  pigsty-pkg-v3.6.1.el9.aarch64.tgz
d598d62a47bbba2e811059a53fe3b2b5  pigsty-pkg-v3.6.1.el9.x86_64.tgz
13fd68752e59f5fd2a9217e5bcad0acd  pigsty-pkg-v3.6.1.u22.aarch64.tgz
c25ccfb98840c01eb7a6e18803de55bb  pigsty-pkg-v3.6.1.u22.x86_64.tgz
0d71e58feebe5299df75610607bf448c  pigsty-pkg-v3.6.1.u24.aarch64.tgz
4fbbab1f8465166f494110c5ec448937  pigsty-pkg-v3.6.1.u24.x86_64.tgz
083d8680fa48e9fec3c3fcf481d25d2f  pigsty-v3.6.1.tgz

See GitHub Release for more details.

1.18 - Pigsty v3.5: 4K Stars, PG18 Beta, 421 Extensions

Originally published on VONNG.

GitHub Release | Release Note

Pigsty v3.5 is officially released. The project has crossed the 4,000+ Star milestone on GitHub — a remarkable achievement for a database infrastructure project.

This version brings a brand-new documentation website, full-platform support for OrioleDB and OpenHalo kernels, Supabase self-hosting optimizations, monitoring system and architecture improvements, PostgreSQL 18 Beta support, routine PG minor version updates, and Apple ARM Vagrant support.

What is Pigsty?

Pigsty is a batteries-included PostgreSQL distribution that works like “self-driving software” for databases. It enables users to spin up enterprise-grade PostgreSQL database services at less than one-tenth the cost of cloud RDS — without needing professional DBAs. Features include high availability, PITR, monitoring, IaC capabilities, and 421 PG ecosystem extensions, running directly on 10 major Linux distributions without containers or Kubernetes.

PostgreSQL 18 Support

PostgreSQL 18 Beta1 has been released, with the stable version coming in September. PG 18 brings powerful new features like AIO, OAuth, and more — now available for preview in Pigsty (not for production use). Routine minor version updates are also available for 17.5, 16.9, 15.13, 14.18, and 13.21.

Pigsty provides a new pg18 configuration template for spinning up highly available RDS based on the PostgreSQL 18 Beta1 kernel. pg_exporter has just released version 1.0, with complete coverage of PG 18’s new monitoring metrics. Users can also use the pig package manager to install PG 18 and corresponding PGDG extensions with a single command.

Supabase Self-Hosting Improvements

Pigsty’s “enterprise-grade” Supabase self-hosting capability has been well-received — the Supabase self-hosting tutorial page traffic even exceeds the landing page. This version further optimizes the Supabase self-hosting workflow.

pgsodium Key Management Integration: You can now specify a root key or provide a key retrieval script for the pgsodium extension that Supabase depends on. This provides data encryption capabilities and can derive a series of subkeys from the root key.

logflare Replication Slot Fix: The Supabase Analytics logflare component has a defect — when system tables have no update writes, it doesn’t update WAL consumption progress, causing replication slots to retain data indefinitely. Pigsty uses a pre-configured cron job supa-kick that executes a “fake update” every minute to trigger progress advancement, preventing disk exhaustion.