Cloud-Native PostgreSQL HA
Stolon PostgreSQL High Availability
Stolon is an open-source, cloud-native PostgreSQL high-availability manager built in Go. Its decoupled architecture segregates database control across three distinct components: keepers, sentinels, and proxies, coordinated through distributed consensus via etcd, Consul, or Kubernetes. Sentinels perform automated leader election and failover in under 30 seconds while proxies shield clients from database topology changes.
Deploy cloud-native PostgreSQL clusters with Stolon. Kubernetes-ready, automatic failover, and seamless scaling for modern applications.
Comprehensive Stolon Services
From initial setup to ongoing management, we provide complete Stolon PostgreSQL solutions for cloud-native environments.
Stolon Implementation
Complete setup and configuration of Stolon clusters with etcd or Consul backends
- Cluster initialization and configuration
- Backend store setup (etcd/Consul)
- Keeper and sentinel deployment
- Proxy configuration and load balancing
Kubernetes Integration
Native Kubernetes deployment with operators and custom resources
- Helm chart deployment
- StatefulSet configuration
- Persistent volume management
- Service mesh integration
High Availability Setup
Automatic failover and recovery with zero-downtime operations
- Automatic leader election
- Streaming replication setup
- Split-brain prevention
- Automated backup and recovery
Multi-Cloud Deployment
Deploy across AWS, GCP, Azure, and hybrid cloud environments
- Cross-region replication
- Cloud provider integration
- Network security configuration
- Disaster recovery planning
Performance Optimization
Fine-tune Stolon and PostgreSQL for maximum performance and efficiency
- Connection pooling optimization
- Resource allocation tuning
- Monitoring and alerting setup
- Performance benchmarking
Migration & Consulting
Expert guidance for migrating to Stolon and ongoing architectural consulting
- Legacy system migration
- Architecture design review
- Best practices training
- 24/7 support and maintenance
Why Choose Stolon for PostgreSQL HA?
Stolon provides cloud-native PostgreSQL clustering with modern DevOps practices and container orchestration. If you run outside Kubernetes, compare it with Patroni and repmgr.
Cloud-Native Architecture
Built for containerized environments with Kubernetes-native deployment and management capabilities.
Automatic Failover
Intelligent failure detection and automatic promotion of standby nodes with minimal downtime.
Flexible Backend Support
Works with etcd, Consul, or Kubernetes for cluster coordination and configuration management.
Zero-Downtime Operations
Perform maintenance, upgrades, and scaling operations without service interruption.
Resilience Engineering
Stolon Production Failure Modes
Critical cloud-native keeper, sentinel, and proxy failure scenarios analyzed and remediated by JusDB DBREs to prevent unmanaged cluster freezes, dead-end proxy routing, and generation desynchronization.
Stolon Proxy Connection Blackholes on Demoted Keeper Unresponsiveness
When a primary keeper process freezes without terminating its listening TCP socket, the stolon-proxy can remain locked to the unresponsive node until sentinel health timeouts trigger, causing client connection timeouts and stalled write transactions.
Fine-tune sentinel sleepInterval and requestTimeout thresholds, configure TCP keepalives on stolon-proxy listeners, and integrate softdog kernel watchdog timers to enforce rapid keeper termination.
DCS Store Quorum Loss and Cluster Freeze (etcd / Consul)
When network partitions or disk saturation impact the underlying etcd or Consul cluster, sentinels lose leader lease quorum and freeze cluster orchestration, blocking standby promotion and leaving postgres in an unmanaged state.
Deploy dedicated 3-to-5 node DCS clusters isolated from database I/O, tune DCS heartbeat timeouts, and configure automated alerting on etcd raft proposal latencies and disk write delays.
Stale Cluster Data Generation Counters during Manual Intervention
Manual modifications to keeper PostgreSQL data directories or incorrect stolonctl update commands without generation counter increments cause sentinels to reject valid standby nodes, leaving the cluster in a degraded replica state.
Enforce strict stolonctl init/update runbook procedures, mandate generation counter validation before manual restarts, and implement automated topology reconciliation scripts.
Cluster Telemetry
Production Stolon Diagnostic Runbooks
Non-blocking command-line commands to inspect live cluster specification, sentinel election health, keeper generation counters, and proxy routing targets.
Inspects live cluster specification, active sentinel leader, keeper health states, and current database generation numbers via stolonctl.
# Query live cluster status, leader keeper, and active generation counter stolonctl --cluster-name=stolon-pg --store-backend=etcdv3 --store-endpoints=http://127.0.0.1:2379 status # Inspect full JSON cluster data including standby replication states and LSNs stolonctl --cluster-name=stolon-pg --store-backend=etcdv3 --store-endpoints=http://127.0.0.1:2379 clusterdata read | jq '.cluster.status' # Check active sentinel leadership and keeper health timers stolonctl --cluster-name=stolon-pg --store-backend=etcdv3 --store-endpoints=http://127.0.0.1:2379 clusterdata read | jq '.sentinelsInfo'
Verifies proxy socket listeners, backend keeper destination mappings, and TCP connection drainage during maintenance windows.
# Verify stolon-proxy process listening status and active client connections ss -tulpn | grep stolon-proxy # Audit stolon-proxy routing target and keeper IP binding in system logs journalctl -u stolon-proxy -n 50 --no-pager | grep -E "(master address|routing to)" # Verify PostgreSQL connectivity through the local stolon-proxy endpoint psql -h 127.0.0.1 -p 5432 -U postgres -d postgres -c "SELECT pg_is_in_recovery(), inet_server_addr();"
Stolon vs Patroni vs CloudNativePG vs RDS
Compare Stolon's decoupled keeper-sentinel-proxy architecture against modern operator patterns and proprietary cloud managed database services.
| Evaluation Vector | JusDB Stolon DBRE | Patroni / CloudNativePG | Managed Cloud (RDS/Aurora) |
|---|---|---|---|
| Decoupled Architecture (Keeper, Sentinel, Proxy) | Independent Go-native processes segregating database management (keeper), cluster leadership (sentinel), and client routing (proxy) for modular resilience | Patroni runs unified Python daemons per node with external proxy dependencies (HAProxy/PgBouncer); CloudNativePG is strictly K8s CRD-coupled | Opaque monolithic managed control plane where proxy routing, failover, and compute layers cannot be tuned or debugged independently |
| DCS-Agnostic Coordination (etcd, Consul, K8s) | Flexible distributed consensus backends supporting etcd, Consul, or native Kubernetes ConfigMaps/Secrets without code refactoring | Patroni supports etcd/Consul/K8s; CloudNativePG is strictly locked to Kubernetes API and cannot run on VMs or bare metal | Proprietary single-vendor storage consensus locking workloads into proprietary cloud regions and hypervisors |
| Failover Speed & Split-Brain Quorum | Sub-30s automated failover with sentinel quorum election, keeper generation counters, and client proxy auto-disconnect on primary demotion | Patroni achieves sub-30s failover with DCS lease ttl; CloudNativePG relies on K8s controller reconciliation loops | Cloud failovers often require 60-120+ seconds of DNS propagation and connection timeout drops across availability zones |
| Maintenance, Modernization & Upgrade Path | Expert lifecycle review and seamless zero-downtime migration pathways from legacy Stolon clusters to modern Patroni or CloudNativePG stacks | Active upstream development communities; however, cross-tool migration from Stolon requires specialized replication bridging | Teams stuck on unmaintained Stolon releases fearing cluster collapse, or forced into disruptive multi-hour cloud migration outages |
| Infrastructure Flexibility (Bare Metal, VMs & K8s) | Consistent high availability topologies deployable uniformly across on-prem bare metal, private cloud VMs, and Kubernetes clusters | CloudNativePG is K8s-only; Patroni spans VMs and K8s; both require separate infrastructure provisioning automation | Strict vendor cloud lock-in preventing portability between on-premises datacenters, AWS, GCP, and private clouds |
| 24/7 Production DBRE & Sub-15m P1 SLA | Continuous stolonctl cluster data inspection, sentinel quorum health checks, senior DBRE on-call 24/7, and guaranteed <15m P1 response | Community Slack/GitHub issues with no emergency SLA, or premium vendor add-on contracts costing tens of thousands annually | Internal engineers trying to diagnose etcd keeper lease timeouts and proxy socket disconnects during major production downtime |
Our Stolon Implementation Process
A systematic approach to deploying production-ready Stolon clusters with comprehensive testing and validation.
Assessment & Planning
Analyze your infrastructure requirements, design cluster topology, and plan the deployment strategy.
Environment Setup
Configure backend stores (etcd/Consul), set up networking, and prepare the deployment environment.
Cluster Deployment
Deploy Stolon components, initialize the cluster, and configure high availability settings.
Testing & Optimization
Perform failover testing, optimize performance, and implement monitoring and alerting.
Stolon Technology Ecosystem
Comprehensive integration with modern cloud-native technologies and orchestration platforms.
PostgreSQL
Core database engine
Kubernetes
Container orchestration
etcd
Distributed key-value store
Consul
Service mesh and discovery
Stolon PostgreSQL HA: Frequently Asked Questions
Common questions about Stolon PostgreSQL implementation and management.
Ready to Deploy Cloud-Native PostgreSQL?
Let our experts help you implement Stolon for reliable, scalable, and cloud-native PostgreSQL high availability.