Model of Patroni Passive Failure
Failover path triggered by node crash causing leader lease expiration and cluster election
Failover path triggered by node crash causing leader lease expiration and cluster election
Entity-Relationship model for INFRA infrastructure nodes in Pigsty, component composition, and naming conventions.
Trade-off analysis for RPO (Recovery Point Objective), finding the optimal balance between availability and data loss.
PostgreSQL primary process crashes while Patroni stays alive and attempts restart, triggering failover after timeout
Why do we need yet another package manager? Especially for Postgres extensions?
Entity-Relationship model for PostgreSQL clusters in Pigsty, including E-R diagram, entity definitions, and naming conventions.
Detailed analysis of worst-case, best-case, and average RTO calculation logic and results across three classic failure detection/recovery paths
Entity-Relationship model for ETCD clusters in Pigsty, including E-R diagram, entity definitions, and naming conventions.
Entity-Relationship model for MinIO clusters in Pigsty, including E-R diagram, entity definitions, and naming conventions.
Entity-Relationship model for Redis clusters in Pigsty, including E-R diagram, entity definitions, and naming conventions.
Understand Pigsty’s core concepts, architecture design, and principles. Master high availability, backup recovery, security compliance, and other key capabilities.
Pigsty’s modular architecture—declarative composition, on-demand customization, flexible deployment.
A node is an abstraction of hardware/OS resources—physical machines, bare metal, VMs, or containers/pods.
How Pigsty abstracts different functionality into modules, and the E-R diagrams for these modules.
Pigsty uses Infrastructure as Code (IaC) philosophy to manage all components, providing declarative management for large-scale clusters.
Pigsty uses Patroni to implement PostgreSQL high availability, ensuring automatic failover when the primary becomes unavailable.
Infrastructure module architecture, components, and functionality in Pigsty.
PostgreSQL module component interactions and data flow.
Pigsty uses pgBackRest to implement PostgreSQL point-in-time recovery, allowing users to roll back to any point in time within the backup policy window.
Trade-off analysis for RTO (Recovery Time Objective), finding the optimal balance between recovery speed and false failover risk.
PITR mechanism: base backup, WAL archive, recovery window, and transaction boundaries
Pigsty PITR architecture: pgBackRest, repositories, and execution flow
Use the configure script to automatically generate recommended configuration files based on your environment.
Fine-tune Pigsty customization using configuration parameters
PITR strategy tradeoffs: repository choice, space planning, and recommendations
Typical PITR scenarios: data deletion, DDL drops, batch errors, branch restore, and site disasters
Use pre-made configuration templates to quickly generate configuration files adapted to your environment
Use PostgreSQL as a CMDB metabase to store Ansible inventory.
How Pigsty’s monitoring system is architected and how monitored targets are automatically managed.
Pigsty uses HAProxy to provide service access, with optional pgBouncer for connection pooling, and optional L2 VIP and DNS access.
Authentication, authorization, encryption, audit, and compliance baseline for database and infrastructure security.
Pigsty defense-in-depth model with layered security baselines from physical to user.
HBA rules, password policy, and certificate auth - who can connect and how to prove identity.
Pigsty provides an out-of-the-box role and privilege model that enforces least privilege.
Pigsty includes a self-signed CA to issue TLS certificates and encrypt network traffic.
Data integrity, backup and recovery, encryption and audit.
Map Pigsty security capabilities and evidence preparation using SOC2 and MLPS Level 3.
Backup scripts, cron jobs, backup repository and infrastructure
HA scenario response plan: When two of three nodes fail and auto-failover doesn’t work, how to recover from the emergency state?
Vanilla PostgreSQL kernel with 440 extensions
How to self-host Supabase with Pigsty, deploy an open-source Firebase alternative with a complete backend stack in one click.
How to deploy a Citus high-availability distributed cluster?
Percona Postgres distribution with TDE transparent encryption support
MySQL compatible Postgres 14 fork
Next-generation OLTP engine for PostgreSQL
How to use other PostgreSQL kernel forks in Pigsty? Such as Citus, Babelfish, IvorySQL, PolarDB, etc.
Deploy native high-availability Citus horizontally sharded clusters with Pigsty, seamlessly scaling PostgreSQL across multiple shards and accelerating OLTP/OLAP queries.
Create Microsoft SQL Server compatible PostgreSQL clusters using WiltonDB and Babelfish! (Wire protocol level compatibility)
Use HighGo’s open-source IvorySQL kernel to achieve Oracle syntax/PLSQL compatibility based on PostgreSQL clusters.
Using Alibaba Cloud’s open-source PolarDB for PostgreSQL kernel to provide domestic innovation qualification support, with Oracle RAC-like user experience.
Using Alibaba Cloud’s commercial PolarDB for Oracle kernel (closed source, PG14, only available in special enterprise edition customization)
How to deploy PostgresML with Pigsty: ML, training, inference, Embedding, RAG inside DB.
Deploy/Monitor Greenplum clusters with Pigsty, build Massively Parallel Processing (MPP) PostgreSQL data warehouse clusters!
Deploy/Monitor Cloudberry clusters with Pigsty, an MPP data warehouse cluster forked from Greenplum!
Use Neon’s open-source Serverless PostgreSQL kernel to build flexible, scale-to-zero, forkable PG services.