HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
sorintlab
stolon
Go2015–2026
sorintlab / stolon

stolon

PostgreSQL cloud native High Availability and more.

22Distinct people
29Mentions
0Explicit recommenders
4.8KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

PostgreSQL cloud native High Availability and more.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year29 dated mentions

Observed mentions: 2015-10-17 11:10:57 UTC to 2026-09-27 12:05:23 UTC.

02468102015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 10 mentions; 2 submissions, 8 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC312
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC211
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC1028
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC303
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC312
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC303
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC211
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC000
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC202

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
stolon - PostgreSQL cloud native High Availability stolon is a cloud native PostgreSQL manager for PostgreSQL high availability. It's cloud native because it'll let you keep an high available PostgreSQL inside your containers (kubernetes integration) but also on every other kind of infrastructure (cloud IaaS, old style infrastructures etc...) For an introduction to stolon you can also take a look at this post Features Leverages PostgreSQL streaming replication. Resilient to any kind of partitioning. While trying to keep the maximum availability, it prefers consistency over availability. kubernetes integration letting you achieve postgreSQL high availability. Uses a cluster store like etcd, consul or kubernetes API server as an high available data store and for leader election Asynchronous (default) and synchronous replication. Full cluster setup in minutes. Easy cluster administration Can do point in time recovery integrating with your preferred backup/restore tool. Standby cluster (for multi site replication and near zero downtime migration). Automatic service discovery and dynamic reconfiguration (handles postgres and stolon processes changing their addresses). Can use pg_rewind for fast instance resynchronization with current master. Architecture Stolon is composed of 3 main components keeper: it manages a PostgreSQL instance converging to the clusterview computed by the leader sentinel. sentinel: it discovers and monitors keepers and proxies and computes the optimal clusterview. proxy: the client's access point. It enforce connections to the right PostgreSQL master and forcibly closes connections to old masters. For more details and requirements see Stolon Architecture and Requirements Documentation Documentation Index Installation Stolon is available in brew. It is unofficial and not supported by the project. So check the version before installing using brew. Step to install using brew Quick start and examples Simple cluster example Kubernetes example Two (or more) nodes setup Project Status Stolon is under active development and used in different environments. Probably its on disk format (store hierarchy and key contents) will change in future to support new features. If a breaking change is needed it'll be documented in the release notes and an upgrade path will be provided. Anyway it's quite easy to reset a cluster from scratch keeping the current master instance working and without losing any data. Requirements PostgreSQL 15, 14, 13, 12, 11, 10, 9.6 etcd2 >= v2.0, etcd3 >= v3.0, consul >= v0.6 or kubernetes >= 1.8 (based on the store you're going to use) OS: currently stolon is tested on GNU/Linux (with reports of people using it also on Solaris, *BSD and Darwin) build To build stolon we usually test and support the latest two major versions of Go like in the Go release policy. make High availability Stolon tries to be resilient to any partitioning problem. The cluster view is computed by the leader sentinel and is useful to avoid data loss (one example over all avoid that old dead masters coming back are elected as the new master). There can be tons of different partitioning cases. The primary ones are covered (and in future more will be added) by various integration tests FAQ See here for a list of faq. If you have additional questions please ask. Contributing to stolon stolon is an open source project under the Apache 2.0 license, and contributions are gladly welcomed! To submit your changes please open a pull request. Contacts For general discussion about using and developing stolon, join the stolon forum For bugs and feature requests file an issue
Read the full README on GitHub

What Hacker News says

29 sources
I haven't found a Go concurrency thing yet that hasn't long-existed in Haskell before. I also find Haskell's concurrency in practice much easier to reason about than Go's, let me do a pitch: In Haskell you can just fork a thread and block till it's done. Threaded, "async" logic just looks like blocking serial code (but isn't blocking). I feel like in typical channel-based Go code I have to jump and scroll a lot in the code because of all the message-passing instead of block-scoped "blocking-style" variable use, and that this makes it hard to conclude whether the whole thing terminates or deadlocks. In Haskell, channels are considered low-level concurrency primitives you should only use when you have no clean high-level primitives for it. This is because they are not "structured" concurrency: When you send something into a channel, it is g
Read the rest
one out of your scope, and you now need to track in your brain where it is, and who should consume that thing in the right way ("message-passing"). For example, in Stolon, a high-availability Postgres orchestrator written in Go (https://github.com/sorintlab/stolon), I found the logic for failover with multiple channels and various timeouts very difficult to reason about when investigating failover bugs. I'm pretty sure that would read much easier in Haskell (see below how). In Haskell, you can start 2, or N, things in parallel, and easily wait till they are done. You can invoke parallel `map` easily. results <- mapConcurrently f mylist If f throws on any element, the whole map throws, and other threads get cancelled automatically as expected. You can get bounded, steaming parallelism, easily. You can set time limits to function calls writing timeout 1000 (myIoFunction ...) You can cancel any thread or computation, at any time. The same timeout function can cancel blocking IO operations, such as reading from the terminal or sockets, without having pass around `Context` objects like in Go (which, if you forget it, just makes things hang or deadlock). You wrap the 2 words "timeout 1000" around your function and done. Concurrency _composes_ in Haskell. You can write res :: Maybe (Maybe a) < timeout a (timeout b (myIoFunction ...)) and the returned type tells you cleanly at which level the cancellation occured (no mixing into the same `error` type. You can build trees of parallel operations that live and die together. And there are no data races (because mutability is a very explicit thing), and I'm not even mentioning STM here (which allows you to do database-style transactions across variables) because that's already pointed out in another post. As a composed example, in Haskell you can write: timeout 1000 (race (downloadUrl ...) (forever (putStrLn "Still loading ..."))) and that will do exactly what you think it should, with correct Ctrl+C cancellability, and good developer ergonomics. If you enjoy concurrency, give Haskell a shot!
In Go Concurrency Distilled
While I generally agree, this is an exaggeration: > This level of production grade fail over and simplicity was point and click, 10 years ago. While some of the tools are _designed_ for point and click, they don't always work. Mostly because of bugs. We run Ceph clusters under our product, and have seen a fair share of non-recoveries after temporary connection loss [1], kernel crashes [2], performance degradations on many small files, and so on. Similarly, we run HA postgres (Stolon), and found bugs in its Go error checking cause failure to recover from crashes and full-disk conditions [3] [4]. This week, we found that full-disk situations will not necessarily trigger failovers. We also found that if DB connections are exhausted, the dameon that's supposed to trigger postgres failover cannot connect to do that (currently testing the fix).
Read the rest
I believe that most of these things will be more figured out with hosted cloud solutions. I agree that self-hosting HA with open-source software is the way to. These softwares are good, and the more people use them, the less bugs they will have. But I wouldn't call it "trivial". If you have large data, it is also brutally cheaper; we could hire 10 full-time sysadmins for the cost of hosting on AWS, vs doing our own Hetzner HA with Free Software, and we only need ~0.2 sysadmins. And it still has higher uptime than AWS. It is true that Proxomox is easy to setup and operate. For many people it will probably work well for a long time. But when things aren't working, it's not so easy anymore. [1]: "Ceph does not recover from 5 minute network outage because OSDs exit with code 0" - https://tracker.ceph.com/issues/73136 [2]: "Kernel null pointer derefecence during kernel mount fsync on Linux 5.15" - https://tracker.ceph.com/issues/53819 [3]: https://github.com/sorintlab/stolon/issues/359#issuecomment-... [4]: https://github.com/sorintlab/stolon/issues/247
In Migrating from DigitalOcean to Hetzner
> I think etcd is basically a k8s only project now I hate etcd with the best of them, but etcd is used in a lot more places than just kubernetes: https://github.com/apache/apisix/blob/master/docs/en/latest/... https://github.com/traefik/traefik#:~:text=Etcd, https://github.com/zalando/patroni#patroni-a-template-for-po... https://github.com/purpleidea/mgmt/tree/0.0.26/etcd (this one shows up on HN quite a bit) https://github.com/sorintlab/stolon#features It's actually one of the major reasons I wouldn't touch those projects
In Ask HN: Are there any open source forks of nomad and consul?
I've not used postgres-on-k8s in any real production workload so my opinion on the matter isn't worth glozing about. I'd rather recommend the blog posts and docs fly.io did on it[1]. They themselves rely on Stolon[2]. AFAIK the secret sauce is postgres' ability for streaming replication[3], ie. pass data across instances as it's ingressed. Add some glue and you've got a cluster. As far as storage goes, k8s supports topology awareness[4] and enables collocating pods and PVs. There are CSI drivers for most file systems you'd encounter in the enterprise[5][6]. > How do you get over the network latency? Ultimately there are incompressible limits you'll hit (CAP theorem and all that). So you do what everybody does in computing : you cheat by exploiting human perception and treating your reads and writes differently[7]. I'm by no means an exper
Read the rest
In Falling for Kubernetes
One of the authors of Patroni here. Automatic failover for PostgreSQL works great and can be done safely if combined with synchronous replication. Multiple tools will implement this correctly: https://patroni.readthedocs.io/en/latest/replication_modes.h... https://github.com/sorintlab/stolon/blob/master/doc/syncrepl... Quoting a former colleague here, but "if it hurts, do it more often". That is what you should do with your PostgreSQL failovers. I have clusters running on timelines in the hundreds without a byte of data loss due to using synchronous replication, tools that help out with leader election, and just doing it often.
In Jepsen: MongoDB 4.2.6
You're technically correct, but this case study was really eye-opening to me: http://blog.sagemath.com/2017/02/09/rethinkdb-vs-postgres.ht... They migrated from a RethinkDB cluster (similar to MongoDB) to a single Postgres server and the result was faster. And a single server is very large today, like 48 cores and 384 GB RAM. And speaking of Postgres HA management, master promotion, etc. there are several tools like https://github.com/sorintlab/stolon available.
In MongoDB's Server Side Public License Is Likely Unenforceable
Sasha's experience running Postgres under Kubernetes started before StatefulSets were a thing, back in the days of PetSets. At the time of his tech diligence the best option appeared to be pg/stolon https://github.com/sorintlab/stolon. The gist of the interview is that there are many more edge cases with HA Postgres + leader election than you can reasonably imagine at first glance. Our experience building and running 24x7x365 HA Kubernetes clusters for clients is almost exclusively in air-gapped or on-premise environments where EBS (or even an IOPS QoS guarantee) does not exist. Most SaaS and managed service provider teams we encounter would much prefer to leverage a cloud provider's primitives than DIY.
In Experiences with running PostgreSQL on Kubernetes

Showing the 15 most recent of 29 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.