Stolon PostgreSQL HA services

Stolon is an Apache-2.0-licensed PostgreSQL high-availability manager. Keepers manage PostgreSQL instances, sentinels compute cluster state, proxies direct client connections to the selected primary, and etcd, Consul, or the Kubernetes API can hold cluster state and coordinate election. Replication is asynchronous by default, with synchronous modes available for eligible designs.

The upstream repository is not marked archived and its README says the project is under active development. However, the latest tagged release listed upstream is v0.17.0 from September 2021, and the README requirements stop at PostgreSQL 15. Treat maintenance, current-version compatibility, image provenance, security response, and support as explicit adoption risks.

Not without comparing current alternatives and support requirements. A new-adoption review should assess Stolon activity, PostgreSQL and Kubernetes compatibility, images, security, operational expertise, migration paths, and vendor or community support against Patroni, repmgr, managed PostgreSQL, or other eligible designs. Existing Stolon estates may justify stabilization while a longer-term decision is made.

No. Data outcome depends on PostgreSQL replication mode, synchronous settings, quorum and network behavior, the promoted standby's replay position, failure timing, and application acknowledgement semantics. Stolon uses asynchronous replication by default. We define explicit recovery-point objectives, test failure cases, and verify transaction outcomes rather than promising lossless failover.

No. Stolon proxy is the client access point that follows the current primary and can close connections to an old primary. It is not a transaction- or session-pooling replacement for PgBouncer. Connection volume, pooling mode, client retry behavior, failover reconnection, DNS or service discovery, and timeout behavior must be designed separately.

We inventory versions, images, keepers, sentinels, proxies, cluster-store quorum, PostgreSQL replication, synchronous settings, fencing, networking, storage, backups, restore, upgrades, observability, certificates, and runbooks. Failure tests cover process, pod, node, network, store, primary, and recovery scenarios with application-visible outcomes recorded.

The path depends on PostgreSQL versions, topology, replication, extensions, storage, downtime tolerance, and target platform. Options can include building a new replica topology, logical replication, backup and restore, or an in-place control-plane transition where supported. The plan needs data validation, connection switching, rollback, failure rehearsal, and ownership handoff.