Leader Election Without etcd: How Far Can You Get With Just Postgres

Sometimes you need exactly one worker doing a thing, one cron runner, one queue sweeper, one sender of the nightly email. The reflexive answer is a coordination service, etcd or ZooKeeper, and the reflexive answer means operating a consensus cluster to protect a cron job. If you already run Postgres, you already run the only coordinator most of these jobs need.

Postgres advisory locks are locks on an arbitrary number you pick, unrelated to any table. First session to ask gets it, everyone else gets told no, and here is the part that makes them perfect for leader election: a session scoped advisory lock releases automatically when the connection dies. Leader crashes, lock frees, someone else grabs it. Liveness handled by the connection itself.

That's the entire election. Worker 20144 asked first and leads, worker 20391 got false and sleeps, retries every few seconds, and takes over the moment the leader's connection drops. Maybe fifteen lines of code around one query.

Honest limits, because they exist. Your leader's reign is tied to a database connection, so aggressive connection poolers and proxies that recycle idle connections will cause elections you did not schedule, use a direct connection for the lock holder. Failover of Postgres itself briefly means no leader, or during a split, ambiguity, so this is not the tool when a moment of two leaders means data corruption. And everything hinges on that one Postgres being your shared source of truth, which for a single region app it already is.

The judgment call: for "at most one, and a few seconds of nobody is fine," Postgres is plenty, and it is one less cluster on the pager rotation. For "exactly one, provably, under partitions," pay the etcd tax. Most jobs are the first kind wearing the second kind's requirements.