Planning Architecture and Nodes

Pigsty uses a modular architecture. You can combine modules like building blocks and express your intent through declarative configuration.

Common Patterns

Here are common deployment patterns for reference. Customize based on your requirements:

Your architecture choice depends on reliability requirements and available resources. Serious production deployments require at least 3 nodes for HA configuration. With only 2 nodes, use Semi-HA configuration.

Trade-offs

• Pigsty monitoring requires at least 1 INFRA node. Production typically uses 2; large-scale deployments use 3.
• PostgreSQL HA requires at least 1 ETCD node. Production typically uses 3; large-scale uses 5. Must be odd numbers.
• Object storage (MinIO) requires at least 1 MINIO node. Production typically uses 4+ nodes in MNMD clusters.
• Production PG clusters typically use at least two-node primary-replica configuration; serious deployments use 3 nodes; high read loads can have dozens of replicas.
• For PostgreSQL, you can also use advanced configurations: offline instances, sync instances, standby clusters, delayed clusters, etc.

Single-Node Setup

The simplest configuration with everything on a single node. Installs four essential modules by default. Typically used for demos, devbox, or testing.

With an external S3/MinIO backup repository providing RTO/RPO guarantees, this configuration works for standard production environments.

Single-node variants:

• Rich (rich): Production single-node template with local MinIO object storage, local software repo, and all PG extensions.
• Slim (slim): Installs only PGSQL and ETCD, no monitoring infra. Slim installation can expand to multi-node HA deployment.
• Infra-only (infra): Opposite of slim—installs only INFRA monitoring infrastructure, no database services, for monitoring other instances.
• Alternative kernels: Replace vanilla PG with derivatives: pgsql, citus, mssql, polar, ivory, mysql, pgtde, oriole, supabase.

Two-Node Setup

Two-node configuration enables database replication and Semi-HA capability with better data redundancy and limited failover support:

Two-node HA auto-failover has limitations. This “Semi-HA” setup only auto-recovers from specific node failures:

• If node-1 fails: No automatic failover—requires manual promotion of node-2
• If node-2 fails: Automatic failover works—node-1 auto-promoted

Three-Node Setup

Three-node template provides true baseline HA configuration, tolerating any single node failure with automatic recovery.

Four-Node Setup

Pigsty Sandbox uses the standard four-node configuration.

For demo purposes, INFRA / ETCD modules aren’t configured for HA. You can adjust further:

More Nodes

With proper virtualization infrastructure or abundant resources, you can use more nodes for dedicated deployment of each module, achieving optimal reliability, observability, and performance.