Categories: Reference

PGSQL is Pigsty’s core module. Ansible inventory declares PostgreSQL clusters; Patroni and etcd provide HA orchestration; pgBackRest provides backup and PITR; HAProxy, VIP, DNS, PgBouncer, and the observability stack expose and monitor database …

The Pigsty v5.0 documentation focuses on Pigsty itself: architecture, installation, deployment, configuration, operations, and the complete manual for every first-party module. v5.0 Docs Preview OINK 0.6.0 Local First Press ⌘+ with K on macOS, or …

In Pigsty, you can replace the native PostgreSQL kernel with different PostgreSQL “flavors” to unlock specialized capabilities. Pigsty supports multiple PostgreSQL kernels and compatibility branches so you can get compatibility layers, multi-master …

How mature is the MYSQL module? It is a pilot module aiming for a simple, inexpensive, good-enough MySQL cluster. The four core capabilities — deployment and convergence, HA failover, daily backups, monitoring and alerting — have been tested …

MYSQL metrics come from mysqld_exporter (raw metrics, mysql_ prefix) and vmalert recording rules (mysql:ins:* / mysql:cls:*). Dashboards and alerts are built on the derived metrics; this page is their dictionary. Common Labels Every metric carries …

The MYSQL module plugs into Pigsty’s observability stack: metrics flow through mysqld_exporter into VictoriaMetrics, error logs flow through Journald/Vector into VictoriaLogs, Grafana ships 5 dashboards, and vmalert loads 68 recording rules plus 27 …

The MYSQL module ships two playbooks: mysql.yml deploys and converges, while mysql-rm.yml performs protected member retirement and cluster teardown. Re-running the former converges toward declared state; the latter is a separate lifecycle operation …

This page covers day-to-day operations for the MYSQL module. The governing principle: declare state in the inventory, converge with the playbook. Most anomalies — a dropped member, drifted AdminAPI state — heal with a single ./mysql.yml -l <cluster> …

The MYSQL deployment role deliberately exposes only 11 parameters; the removal role adds 2 protected operations parameters. Software versions, ports, directories, charset, TLS paths, and timer schedules are fixed by the role; memory sizing is derived …

The MYSQL module is driven by the inventory: you declare the desired cluster, and mysql.yml converges the live state to match. This page covers topology planning and every configuration block; see Parameters for the full reference. Before You Deploy …

MySQL is one of the world’s most popular open-source relational databases. Pigsty’s MYSQL module deploys a fixed, native MySQL 8.4 LTS platform on managed nodes: either a standalone instance or a three-node single-primary InnoDB Cluster built on …

How mature is the current KAFKA module? The current role implements a production-grade v1 baseline: dynamic KRaft, full cluster guardrails, cold-start/repair, serial broker admission and dynamic controller join, member retirement (including dead …

The KAFKA module uses two kinds of metric sources, both registered under the same job=kafka scrape job: the JMX target (with a role label) collects the internal state of each JVM, while the protocol exporter target (without a role label) collects the …

Pigsty gives the KAFKA module a unified observability stack that combines metrics, logs, dashboards, and alerts. Monitoring covers both the Kafka JVM internals and the Kafka protocol view, so you never end up seeing only that the process is alive …

The KAFKA role deliberately exposes only 15 persistent parameters. Details such as topology, listeners, security implementation, storage subdirectories, replication safety, and Exporter placement are derived by the role in a single, consistent way, …

The KAFKA module expresses cluster intent through 15 persistent public parameters; everything else — topology, listeners, storage subdirectories, replication safety, authorization, and Exporter placement — is derived by the role in a single, …

Kafka is a distributed event-streaming platform. Pigsty’s KAFKA module deploys Apache Kafka 4.1+ dynamic KRaft clusters on managed nodes from RPM/DEB packages, with unified management of security, resources, lifecycle, and observability. Current …

Deployment code-server package not found Ensure NODE and repo config are in place: yum repolist # EL apt-cache policy # Debian/Ubuntu, read-only inspection ./infra.yml -l infra -t repo --check JupyterLab installation failed jupyter_venv must exist: …

VIBE monitoring mainly focuses on Claude Code OpenTelemetry data. Code-Server and JupyterLab do not expose Prometheus metrics; use systemd and logs for health checks. Claude Code Observability VIBE writes default OpenTelemetry env vars into …

VIBE module has 18 parameters, grouped as: Common Code-Server JupyterLab Node.js Claude Code Codex CLI Overview Parameter Type Level Default Description vibe_data path C /fs Workspace dir code_enabled bool C true Enable Code-Server code_port port C …

VIBE supports enabling components on demand and exposes services via a unified workspace and Nginx portal. Overview Component Enable Param Default Description Code-Server code_enabled Enabled VS Code in browser JupyterLab jupyter_enabled Disabled …

The VIBE module provides a browser-based dev environment with Code-Server, JupyterLab, Node.js, Claude Code, and Codex CLI, and can work with JUICE shared storage and PGSQL database capabilities. VIBE depends on NODE and INFRA: NODE provides base …

Port Conflicts? Multiple instances on the same node must use different port values. Example: juice_instances: fs1: path: /fs1 meta: postgres://... port: 9567 fs2: path: /fs2 meta: postgres://... port: 9568 Why does changing data not take effect? …

JuiceFS instances expose Prometheus metrics via juicefs mount --metrics. In JUICE, metrics listen on 0.0.0.0:<port>, default port 9567. Monitoring Architecture JuiceFS Mount (metrics: 0.0.0.0:<port>) ↓ VictoriaMetrics (scrape) ↓ Grafana Dashboard If …

JUICE module has 2 parameters: juice_cache: shared cache directory juice_instances: instance definition dict Parameter Overview Parameter Type Level Description juice_cache path C JuiceFS shared cache directory juice_instances dict I JuiceFS instance …

Concepts and Implementation JuiceFS consists of a metadata engine and data storage. In the current version, meta is passed through to juicefs as the metadata engine URL, and PostgreSQL is typically used in production. Data storage is defined by data …

JuiceFS is a high-performance POSIX-compatible distributed filesystem that can mount object storage or databases as a local filesystem. The JUICE module depends on NODE for infrastructure and package repo, and typically uses PGSQL as the metadata …

Who Can Run Docker Commands? By default, Pigsty adds both the management user running the playbook on the remote node (i.e., the SSH login user on the target node) and the admin user specified in the node_admin_username parameter to the Docker …

This snapshot records 123 monitoring metric families for the DOCKER module. The metrics present at runtime vary with package version, enabled collectors, and target state. Metric Name Type Labels Description builder_builds_failed_total counter ip, …

The DOCKER module provides 8 configuration parameters. Parameter Overview The DOCKER parameter group is used for Docker container engine deployment and configuration, including enable switch, data directory, storage driver, registry mirrors, and …

Pigsty has built-in Docker support, which you can use to quickly deploy containerized applications. Getting Started Docker is an optional module. In Pigsty, whether Docker is installed is controlled by docker_enabled, which is disabled by default. …

Docker is the most popular containerization platform, providing standardized software delivery capabilities. Pigsty does not rely on Docker to deploy any of its components; instead, it provides the ability to deploy and install Docker — this is an …

ABORT due to redis_safeguard enabled This means the Redis instance you are trying to remove has the safeguard enabled. When redis_safeguard is true, redis-rm.yml refuses to run unconditionally; the switch does not probe whether an instance is …

This page is a snapshot of 275 monitoring metric categories for the REDIS module. The actual runtime metric set varies with package version, enabled collectors, and target state. Metric Name Type Labels Description ALERTS Unknown cls, ip, level, …

Dashboards The REDIS module provides 3 monitoring dashboards: Redis Overview: Overview of all Redis clusters Redis Cluster: Details of a single Redis cluster Redis Instance: Details of a single Redis instance Monitoring Pigsty provides three …

The REDIS module has 22 parameters: 19 for Redis/Valkey deployment and configuration, and 3 for removal. Parameter Overview The REDIS parameter group is used for Redis cluster deployment and configuration, including identity, instance definitions, …

Concept The entity model of Redis is almost the same as that of PostgreSQL, which also includes the concepts of Cluster and Instance. Note that the Cluster here does not refer to the native Redis Cluster mode. The core difference between the REDIS …

REDIS is Pigsty’s Redis-compatible cache module. Choose Redis or Valkey with redis_type; the default remains redis. Both engines support primary-replica replication, Sentinel, and native cluster mode while sharing configuration paths, instance …

Which backend does the MINIO module deploy by default? In v4.5.0, the current source deploys Silo—and only Silo. The only valid value for minio_type is silo. MINIO remains the compatibility module name; it does not mean the MinIO server is running. …

The MINIO module collects Silo metrics through /minio/metrics/v3. The metric set varies with server versions and enabled features, so this page documents the stable interfaces used by current dashboards and alerts rather than treating a complete …

Administration UI Silo provides an administration UI through minio_admin_port, which defaults to 9001. Access it directly at https://<node-ip>:9001. Some configuration templates also expose the administration entry point at m.pigsty. Login …

The MINIO module exposes 22 public parameters in two groups: MINIO: 19 parameters for deploying Silo object-storage clusters MINIO_REMOVE: 3 parameters controlling object-storage cluster removal Architecture Change: Pigsty v3.6+ Since Pigsty v3.6, …

Before deploying the MINIO module, define a Silo object-storage cluster in the config inventory. The current role requires minio_type: silo and supports these inventory deployment modes: Single-Node Single-Disk: SNSD: Single-node single-disk mode, …

After you configure and deploy Silo with the playbook, use this page to access it through the compatible S3 and mcli interfaces. Deploy Cluster First, define a single-node, single-disk object-storage cluster in the config inventory and explicitly pin …

MINIO is Pigsty’s compatibility module name for S3-compatible object storage. The current role deploys Silo, and minio_type accepts only silo. Silo preserves the MinIO S3/Admin APIs, MINIO_* environment variables, disk format, and mcli client …

What is etcd’s role in Pigsty? etcd is a distributed, reliable key-value store for critical system data. Pigsty uses etcd as DCS (Distributed Config Store) service for Patroni, storing PG HA status. Patroni uses etcd for: cluster failure detection, …

This snapshot records 177 monitoring metric families for the ETCD module. The metrics present at runtime vary with package version, enabled collectors, and target state. Metric Name Type Labels Description etcd:ins:backend_commit_rt_p99_5m Unknown …

Dashboards ETCD module provides one monitoring dashboard: Etcd Overview. ETCD Overview Dashboard ETCD Overview: Overview of ETCD cluster Dashboard provides key ETCD status info. Notable: ETCD Aliveness—shows overall etcd cluster service status. Red …

The ETCD module has 13 parameters, divided into two sections: ETCD: 10 parameters for etcd cluster deployment and configuration ETCD_REMOVE: 3 parameters for controlling etcd cluster removal Architecture Change: Pigsty v3.6+ Since Pigsty v3.6, the …

Before deployment, define etcd cluster in config inventory. Typical choices: One Node: No HA, suitable for dev, test, demo, or standalone deployments using external S3 backup for PITR Three Nodes: Basic HA, tolerates 1 node failure, suitable for …

ETCD is a distributed, reliable key-value store for critical system config data. Pigsty uses etcd as DCS (Distributed Config Store), critical for PostgreSQL HA and automatic failover. The ETCD module depends on NODE module and is required by PGSQL …

How to configure NTP service? NTP is critical for various production services. If NTP is not configured, you can use public NTP services or the Chronyd on the admin node as the time standard. If your nodes already have NTP configured, you can …

This page is a snapshot of 727 monitoring metric categories for the NODE module. The actual runtime metric set varies with package version, enabled collectors, and target state. Metric Name Type Labels Description ALERTS Unknown alertname, ip, level, …

Pigsty currently provides 10 monitoring dashboards in the NODE dashboard directory, along with comprehensive alerting rules. Dashboards The NODE dashboard directory currently contains 10 dashboards. The JuiceFS and Claude Code dashboards show data …

The NODE module tunes target nodes into the desired state and integrates them into the Pigsty monitoring system. Parameter Section Description NODE_ID Node identity parameters NODE_DNS Node DNS resolution NODE_PACKAGE Upstream repo & package install …

Pigsty uses IP address as the unique identifier for nodes. This IP should be the internal IP address on which the database instance listens and provides external services. node-test: hosts: 10.10.10.11: { nodename: node-test-1 } 10.10.10.12: { …

Tune nodes into the desired state and monitor it, manage node, VIP, HAProxy, and exporters.

This section covers daily administration and operations for Pigsty deployments.

What components are included in the INFRA module? Strictly following the current source, the infra role directly manages: Nginx: Exposes Grafana, VictoriaMetrics (VMUI), Alertmanager, and other WebUIs, and hosts local YUM/APT repositories. DNSMasq: …

Note: Pigsty v4.0 has replaced Prometheus/Loki with VictoriaMetrics/Logs/Traces. The following metric list is still based on v3.x generation, for reference when troubleshooting older versions only. To get the latest metrics, query directly in …

This document describes monitoring dashboards and alert rules for the INFRA module in Pigsty. Dashboards Pigsty provides the following monitoring dashboards for the Infra module: Dashboard Description Pigsty Home Pigsty monitoring system homepage …

The INFRA module is responsible for deploying Pigsty’s infrastructure components: local software repository, Nginx, DNSMasq, VictoriaMetrics, VictoriaLogs, Grafana, Alertmanager, Blackbox Exporter, and other monitoring and alerting infrastructure. …

Configuration Guide INFRA = primarily monitoring infrastructure, optional for PostgreSQL databases. Unless manually configured to depend on DNS/NTP services on INFRA nodes, INFRA module failures typically don’t affect PG cluster operations. Single …

Configuration | Administration | Playbooks | Monitoring | Parameters Overview Every Pigsty deployment includes a set of infrastructure components that provide services for managed nodes and database clusters: Component Port Description Nginx 80/443 …

Pigsty provides supplementary extension repositories, offering additional extension packages on top of the PGDG official repository. YUM Repository Applicable to EL 8/9/10 and compatible systems (RHEL, Rocky, AlmaLinux, CentOS, etc.). Add Repository …

Why can’t my current user use the pg admin alias? Starting from Pigsty v4.0, permissions to manage global Patroni / PostgreSQL clusters using the pg admin alias have been tightened to the admin group (admin) on admin nodes. The admin user (dba) …

Pigsty installs and enables some core extensions by default when initializing PostgreSQL clusters. Default Installed Extensions Extensions installed by default via pg_packages: Extension Description pg_repack Handle table bloat online, important …

Removing extensions involves two levels: dropping extension objects (database level) and uninstalling packages (operating system level). Drop Extension Objects Use DROP EXTENSION to remove extensions from the database: -- Drop extension DROP …

Extension updates involve two levels: package updates (operating system level) and extension object updates (database level). Update Packages Use package managers to update extension packages: # EL systems sudo yum update pgvector_18* # Debian/Ubuntu …

After installing extension packages, you need to execute CREATE EXTENSION in the database to use extension features. View Available Extensions After installing extension packages, you can view available extensions: -- View all available extensions …

Some extensions require preloading dynamic libraries or configuring parameters before use. This section describes how to configure extensions. Preload Extensions Most extensions can be enabled directly with CREATE EXTENSION after installation, but …

Before installing extensions, ensure that extension packages are downloaded to the local repository or available from upstream. Default Behavior Pigsty downloads the base PostgreSQL 18 kernel packages to the local software repository by default. The …

Pigsty uses a package alias mechanism to simplify extension installation and management. Package Alias Mechanism Managing extensions involves multiple layers of name mapping: Layer Example pgvector Example postgis Extension Name vector postgis, …

Extensions are the soul of PostgreSQL. Pigsty includes 575 pre-compiled, out-of-the-box extension plugins, fully unleashing PostgreSQL’s potential. What are Extensions PostgreSQL extensions are a modular mechanism that allows enhancing database …

Pigsty provides four preset Patroni/PostgreSQL config templates optimized for different workloads: Template CPU Cores Use Case Characteristics /docs/pgsql/template/oltp.yml 4-128C OLTP transactions High concurrency, low latency …

You can define an OPTIONAL L2 VIP on a PostgreSQL cluster, provided that all nodes in the cluster are in the same L2 network. This VIP works on Master-Backup mode and always points to the node where the primary instance of the database cluster is …

Pigsty provides 575 packaged extensions, covering 16 major categories including time-series, geospatial, vector, full-text search, analytics, and feature enhancements, ready to use out-of-the-box. Using extensions in Pigsty involves four core steps: …

The PGSQL module needs to be installed on nodes managed by Pigsty (i.e., nodes that have the NODE module configured), and also requires an available ETCD cluster in your deployment to store cluster metadata. Installing the PGSQL module on a single …

The PGSQL module provides 638 available monitoring metrics. Metric Name Type Labels Description ALERTS Unknown category, job, level, ins, severity, ip, alertname, alertstate, instance, cls N/A ALERTS_FOR_STATE Unknown category, job, level, ins, …

Pigsty provides numerous out-of-the-box Grafana monitoring dashboards for PostgreSQL: Demo & Gallery. The current source provides 31 PostgreSQL-related dashboards: 29 PostgreSQL / PGCAT dashboards under files/grafana/pgsql, plus two PGLOG dashboards …

This document introduces Pigsty’s monitoring system architecture, including metrics, logs, and target management. It also covers how to monitor existing PG clusters and remote RDS services. Monitoring Overview Pigsty uses a modern observability stack …

Parameters and reference documentation

Pigsty includes a built-in playbook pgsql-migration.yml that implements online database migration based on logical replication. With pre-generated automation scripts, application downtime can be reduced to just a few seconds. However, note that …

Detailed explanation of Host-Based Authentication (HBA) in Pigsty. Authentication is the foundation of Access Control and Default Privileges. PostgreSQL supports several authentication methods. Here we mainly introduce HBA: Host Based …

In this context, Database refers to the logical object created using the SQL command CREATE DATABASE within a database cluster. A PostgreSQL server can serve multiple databases simultaneously. In Pigsty, you can define the required databases in the …

In this context, users refer to logical objects within a database cluster created using the SQL commands CREATE USER/ROLE. In PostgreSQL, users belong directly to the database cluster rather than to a specific database. Therefore, when creating …

Pigsty uses pgBackRest for PostgreSQL backups. It supports full, differential, and incremental backups, parallel processing, encryption, and Silo/S3 object storage. Every PGSQL cluster is configured for backup and WAL archiving by default. This …

Database administration and operation tasks

Pigsty access-control documentation is organized by purpose: Access Control Concepts: role model, default privileges, database ACLs, and instance-isolation boundaries. Access Control Configuration: pg_default_roles, pg_users, pg_default_privileges, …

Separate read and write operations, route traffic correctly, and deliver PostgreSQL cluster capabilities reliably. Service is an abstraction: it is the form in which database clusters provide capabilities to the outside world and encapsulates the …

PostgreSQL security combines authentication, authorization, network boundaries, encrypted communication, data protection, and operational process. Pigsty provides configuration entry points for these mechanisms; operators must still harden, verify, …

Split read and write operations, route traffic correctly, and reliably deliver PostgreSQL cluster capabilities. Service is an abstraction: it is the form in which database clusters provide capabilities externally, encapsulating the details of the …

Pigsty is a “configuration-driven” PostgreSQL platform: all behaviors come from the combination of inventory files in ~/pigsty/conf/*.yml and PGSQL parameters. Once you’ve written the configuration, you can replicate a customized cluster with …

demo/wool targets small cloud instances in China and defaults to region: china, PostgreSQL 18, and the tiny tuning profiles. Overview Config Name: demo/wool Node Count: Single node Suggested Size: Approximately 2 vCPU / 2 GB for testing Related: …

Core concepts and architecture design

demo/saas is a legacy feature-rich single-node example with predefined business users, databases, and application entrypoints. It demonstrates how PostgreSQL, Silo, Redis, Docker, and the portal can be combined. Overview Config Name: demo/saas Node …

demo/remote deploys no local PostgreSQL cluster. Instead, it declares multiple pg_exporters on an INFRA node to monitor remote PostgreSQL, PolarDB, or cloud RDS instances. Overview Config Name: demo/remote Local Node Count: One INFRA node Example …

The build/dev configuration template is Pigsty’s three-node local build and development environment. It is used to validate repository build and package download workflows across EL9, Debian 12, and Ubuntu 24 nodes. This template is intended only for …

The build/oss configuration template is the build environment configuration for Pigsty open-source edition offline packages, used to batch-build offline installation packages across multiple operating systems. This configuration is intended for …

demo/mysql is the four-node example for the native MySQL 8.4 LTS pilot module. It is distinct from conf/mysql.yml, which provides MySQL protocol compatibility through the OpenHalo PostgreSQL kernel. Overview Config Name: demo/mysql Node Count: 4 …

demo/kafka declares two Kafka 4.x dynamic KRaft clusters across four nodes: the plaintext single-node development cluster kf-meta, and the three-node TLS/SCRAM/ACL demonstration cluster kf-test. Overview Config Name: demo/kafka Node Count: 4 kf-meta: …

demo/redis demonstrates standalone/replica, Sentinel, and native Cluster modes supported by Pigsty’s Redis module in one configuration. Overview Config Name: demo/redis Node Count: 4 Clusters: redis-ms, redis-meta, redis-test Related: demo/demo …

demo/minio demonstrates a highly available S3 object-storage cluster with four nodes and four drives per node, for 16 drives total. The template retains MINIO module compatibility naming and explicitly sets minio_type: silo; the current v4.5.0 source …

The demo/kernel configuration template demonstrates the major PostgreSQL kernels and compatible branches supported by Pigsty in a single configuration. It is intended for feature validation and kernel difference testing, not production use. Overview …

The demo/demo configuration template is used by Pigsty’s public demo site, demonstrating how to expose services publicly, configure SSL certificates, and install all available extensions. If you want to set up your own public service on a cloud …

The demo/debian configuration template is optimized for Debian and Ubuntu distributions. Overview Config Name: demo/debian Node Count: Single node Description: Debian/Ubuntu optimized configuration template OS Distro: d12, d13, u22, u24, u26 OS Arch: …

The demo/el configuration template is optimized for Enterprise Linux family distributions (RHEL, Rocky Linux, Alma Linux, Oracle Linux). Overview Config Name: demo/el Node Count: Single node Description: Enterprise Linux optimized configuration …

demo/bare is Pigsty’s smallest configuration example. It keeps only three core groups and three global parameters to show a working inventory skeleton. Overview Config Name: demo/bare Node Count: Single node Modules: INFRA, ETCD, PGSQL Related: meta, …

The ha/citus template deploys a complete Citus distributed PostgreSQL cluster with 1 infra node, 1 coordinator group, and 5 worker groups (12 Citus nodes total), providing transparent horizontal scaling and data sharding. Overview Config Name: …

The ha/dual template uses two-node deployment, implementing a “semi-HA” architecture with one primary and one standby. If you only have two servers, this is a pragmatic choice. Overview Config Name: ha/dual Node Count: Two nodes Description: Two-node …

Three nodes is the minimum scale for majority-based high availability. The ha/trio template distributes INFRA, ETCD, PGSQL, and Silo across three servers. PostgreSQL, ETCD, and object storage continue serving when one server is unavailable. Overview …

ha/safe uses a three-node high-availability topology to demonstrate TLS, client certificates, password checks, backup encryption, the CRIT parameter template, and related security settings. It is a configuration example to customize, not a …

Getting Started Path Order Question Entry 1 What modules does Pigsty include? Modular Architecture, PGSQL Architecture, PGSQL Cluster Model 2 How do I get it running first? Quick Start, Web UI, PostgreSQL Quick Start 3 How should I read the config …

The ha/full configuration template is Pigsty’s recommended sandbox demonstration environment, deploying two PostgreSQL clusters across four nodes for testing and demonstrating various Pigsty capabilities. Most Pigsty tutorials and examples are based …

ha/octo uses the first eight nodes from vagrant/spec/deci.rb to build a compact high-availability simulation. It exercises co-located modules, VIPs, remote backup, and larger membership counts. Do not use it directly as a production blueprint without …

The ha/simu configuration template is a 20-node production environment simulation, requiring a powerful host machine to run. Overview Config Name: ha/simu Node Count: 20 nodes, pigsty/vagrant/spec/simu.rb Description: 20-node production environment …

Use -c with configure to select a template. Its value is a path relative to conf/ without the .yml suffix. If omitted, Pigsty uses the default meta template. Category Templates Solo Templates meta, rich, fat, slim, infra, vibe, docker Kernel …

The mongo configuration template is a PostgreSQL deployment mode, not an independent Pigsty module. It combines: PostgreSQL 18 managed by the standard PGSQL module The documentdb extension and its required preload libraries A stateless FerretDB proxy …

This page lists default ports used by Pigsty module components. Adjust as needed or use as a reference for fine-grained firewall configuration. Module Component Port Parameter Status NODE node_exporter 9100 node_exporter_port Enabled NODE haproxy …

The oriole configuration template uses OrioleDB storage engine instead of PostgreSQL’s default Heap storage, providing bloat-free, high-performance OLTP capability. Overview Config Name: oriole Node Count: Single node Description: OrioleDB bloat-free …

This page summarizes Pigsty v4.x playbook entries and usage guidance by module. For detailed task tags, open each module’s playbook page. Module Playbook Navigation Module Count Playbooks INFRA 3 deploy.yml infra.yml infra-rm.yml NODE 2 node.yml …

The pgtde configuration template uses Percona PostgreSQL database kernel, providing Transparent Data Encryption (TDE) capability. Overview Config Name: pgtde Node Count: Single node Description: Percona PostgreSQL transparent data encryption …

This is the parameter navigation page for Pigsty v4.x, without repeating full explanations for each parameter. For parameter details, please read each module’s param page. Cross-checked against the current source and parameter reference pages, the 10 …

The mysql configuration template uses OpenHalo database kernel instead of native PostgreSQL, providing MySQL wire protocol and SQL syntax compatibility. Overview Config Name: mysql Node Count: Single node Description: OpenHalo MySQL-compatible kernel …

Pigsty FHS Pigsty’s home directory is located at ~/pigsty by default. The file structure within this directory is as follows: ~/pigsty Source Tree app/Application template resourcesbin/Management and operations scriptsfiles/victoria/Rules and …

The pgedge configuration template replaces native PostgreSQL with the pgEdge kernel and provides distributed, multi-master capabilities for edge deployments. For the full guide, see: pgEdge kernel guide. For kernel differences and version references, …

Official Modules Module Category Status Docs Path Summary PGSQL Core GA /docs/pgsql High-availability PostgreSQL clusters with built-in backup, monitoring, SOP, and extension ecosystem. INFRA Core GA /docs/infra Local software repository + …

Pigsty runs on Linux, supporting amd64/x86_64 and arm64/aarch64 arch, plus 3 major distros: EL, Debian, Ubuntu. Pigsty runs bare-metal without containers. Supports actively maintained mainstream releases across the 3 major distro families and both …

The agens configuration template replaces native PostgreSQL with the AgensGraph kernel and enables property-graph modeling plus Cypher queries. For the full guide, see: AgensGraph kernel guide Overview Config name: agens Node count: Single node …

The ivory configuration template uses Highgo’s IvorySQL database kernel instead of native PostgreSQL, providing Oracle syntax and PL/SQL compatibility. For the complete tutorial, see: IvorySQL (Oracle Compatible) Kernel Guide Overview Config Name: …

The cloudberry config template is not available yet in this version. If you need Cloudberry support, please see: Kernel: Cloudberry Config Templates

The polar configuration template uses Alibaba Cloud’s PolarDB for PostgreSQL database kernel instead of native PostgreSQL, providing “cloud-native” Aurora-style storage-compute separation capability. For the complete tutorial, see: PolarDB for …

The mssql configuration template uses a PostgreSQL 17-compatible Babelfish kernel instead of native PostgreSQL, providing Microsoft SQL Server wire protocol (TDS) and T-SQL syntax compatibility. The current template is pinned to pg_version: 17; …

pg19 is the single-node PostgreSQL 19 Beta evaluation template. It follows the meta topology, enables the beta repository, and limits the local repository’s additional cache to core PGSQL packages without preinstalling extensions. Overview Config …

The pgsql configuration template uses the native PostgreSQL kernel, Pigsty’s default database kernel, with stable support for PostgreSQL 14 to 18. The current configure also accepts version 19, but PG19 remains Beta; use the dedicated pg19 template …

The docker configuration template runs Pigsty inside a Docker container and provides a minimal single-node stack for infrastructure and PostgreSQL. For full workflow details, see Docker Deployment. Overview Config Name: docker Node Count: Single node …

The vibe config template provides a ready-to-use AI coding sandbox, integrating Code-Server (Web VS Code), JupyterLab, Claude Code observability, Codex CLI, JuiceFS distributed filesystem, and a feature-rich PostgreSQL database. Overview Config Name: …

The infra configuration template only deploys Pigsty’s observability infrastructure components (VictoriaMetrics/Grafana/VictoriaLogs/Nginx, etc.), without PostgreSQL and etcd. Suitable for scenarios requiring a standalone monitoring stack, such as …

The fat configuration template is Pigsty’s Feature-All-Test template, installing all extension plugins on a single node and building a local software repository containing all extensions for PostgreSQL 14-18 (five major versions). This is a …

The slim configuration template provides minimal installation capability, installing a PostgreSQL high-availability cluster directly from the internet without deploying Infra monitoring infrastructure. When you only need an available database …

The rich configuration template is an enhanced version of meta, designed for users who need to experience complete functionality. If you want to build a local software repository, use Silo for backup storage, run Docker applications, or need …

The meta configuration template is Pigsty’s default template, designed to fulfill Pigsty’s core functionality—deploying PostgreSQL—on a single node. To maximize compatibility, meta installs only the minimum required software set to ensure it runs …

China PostgreSQL Ecosystem Projects Sorted by GitHub stars in descending order. Last updated: 2026-08-13 (Beijing time). Project Star Author Type Summary pgsty/pigsty 5521 Ruohang Feng @ PGSTY Distribution Out-of-the-box PostgreSQL distribution …

Overview The cost data below is intended to illustrate order-of-magnitude differences. Cloud vendor pricing and discounts vary over time, region, instance size, and purchase model. EC2 Core·Month RDS Core·Month DHH Self-Hosted Core-Month Price (192C …

Comparison with RDS Pigsty is a local-first RDS alternative released under Apache-2.0, deployable on your own physical/virtual machines or cloud servers. We’ve chosen Amazon AWS RDS for PostgreSQL (the global market leader) and Alibaba Cloud RDS for …

What is Pigsty, and what is it not? Pigsty is a PostgreSQL database distribution, a local-first open-source RDS cloud database solution. Pigsty is not a Database Management System (DBMS), but rather a tool, distribution, solution, and best practice …

Pigsty aims to unite the power of the PostgreSQL ecosystem and help users make the most of the world’s most popular database, PostgreSQL, with self-driving database management software. While Pigsty itself has already resolved many issues in …

According to Google Analytics PV and download statistics, Pigsty currently has approximately 100,000 users, with half from mainland China and half from other regions globally. They span across multiple industries including internet, cloud computing, …

Sponsor Us Pigsty is a free and open-source software, passionately developed by PostgreSQL community members, aiming to integrate the power of the PostgreSQL ecosystem and promote the widespread adoption of PostgreSQL. If our work has helped you, …

License Summary Pigsty core uses Apache-2.0; documentation uses CC BY 4.0. Official License: https://github.com/pgsty/pigsty/blob/main/LICENSE Pigsty Core The Pigsty core is licensed under Apache License 2.0. Apache-2.0 is a permissive open-source …

Pigsty Software When you install Pigsty software, if you use offline package installation in a network-isolated environment, we will not receive any data about you. If you choose online installation, when downloading related packages, our servers or …

GitHub Our GitHub repository is: https://github.com/pgsty/pigsty. Please give us a ⭐️ star! We welcome anyone to submit new Issues or create Pull Requests, propose feature suggestions, and contribute to Pigsty. Please note that for issues related to …

Release Strategy Pigsty uses semantic versioning: <major>.<minor>.<patch>. Alpha/Beta/RC versions will have suffixes like -a1, -b1, -c1 appended to the version number. Major version updates signify incompatible foundational changes and major new …

PostgreSQL parameters can be configured at multiple levels with different scopes and precedence. Pigsty supports four configuration levels, from global to local: Level Scope Configuration Method Storage Location Cluster All instances in cluster …

Access control combines roles, object privileges, database ACLs, and HBA. This page covers configuration parameters; see Access Control Concepts for design and boundaries. Pigsty provides a compact ACL model described by these parameters: …

Overview HBA (Host-Based Authentication) controls “who can connect to the database, from where, and how”. See Authentication for the authentication model and default rules. Pigsty manages HBA rules declaratively through pg_default_hba_rules and …

tiny.yml is optimized for micro instances and resource-constrained environments. Designed for 1-3 core CPUs with minimal resource usage, conservative memory allocation, and disabled parallel queries. Pair with node_tune = tiny for OS-level tuning. …

In this document, “database” refers to a logical object within a database cluster created with CREATE DATABASE. A PostgreSQL cluster can serve multiple databases simultaneously. In Pigsty, you can define required databases in cluster configuration. …

In this document, “user” refers to a logical object within a database cluster created with CREATE USER/ROLE. In PostgreSQL, users belong directly to the database cluster rather than a specific database. Therefore, when creating business databases …

crit.yml targets transactional workloads with elevated consistency and audit requirements. It forces data checksums and Patroni strict synchronous mode, adds connection logging, and adjusts selected WAL, timeout, and parallel-query parameters. The …

PostgreSQL package naming conventions vary significantly across different operating systems: EL systems (RHEL/Rocky/Alma/…) use formats like pgvector_18, postgis36_18* Debian/Ubuntu systems use formats like postgresql-18-pgvector, …

olap.yml is optimized for online analytical processing (OLAP). Designed for 4-128 core CPUs with support for large queries, high parallelism, relaxed timeouts, and aggressive vacuum. Pair with node_tune = olap for OS-level tuning. Use Cases OLAP …

Recent News 2026-07-10: Pigsty v4.4.0 officially released: PG19 beta support and 531 extensions Release Notes: v4.4.0 Highlights: PostgreSQL 18.4 / 19 beta support, 531 total extensions, kernel and package updates, and Pig CLI improvements. …

oltp.yml is Pigsty’s default config template, optimized for online transaction processing (OLTP). Designed for 4-128 core CPUs with high concurrency, low latency, and high throughput. Pair with node_tune = oltp for OS-level tuning. Use Cases OLTP …

Choosing a “kernel” in Pigsty means determining the PostgreSQL major version, mode/distribution, packages to install, and tuning templates to load. The Pigsty v4.5 source currently supports PostgreSQL 14-18 and uses 18 by default. The following …

Historical Origins The Pigsty project began in 2018-2019, originating from Tantan. Tantan is an internet dating app — China’s Tinder, now acquired by Momo. Tantan was a Nordic-style startup with a Swedish engineering founding team. Tantan had …

Pigsty provides four scenario-based parameter templates by default, which can be specified and used through the pg_conf parameter. tiny.yml: Optimized for small nodes, VMs, and demos (the template is labeled for 1-3 cores) oltp.yml: Optimized for …

“PostgreSQL In Great STYle”: Postgres, Infras, Graphics, Service, Toolbox, it’s all Yours. —— Battery-included, local-first PostgreSQL distribution, open-source RDS alternative Value Propositions Extensibility: Powerful extensions out of the box: …

Choose the appropriate instance and cluster types based on your requirements to configure PostgreSQL database clusters that meet your needs. You can define different types of instances and clusters. Here are several common PostgreSQL …