public inbox for [email protected]  
help / color / mirror / Atom feed
From: Konstantin Osipov <[email protected]>
To: Aleksander Alekseev <[email protected]>
Cc: [email protected]
Subject: Re: Built-in Raft replication
Date: Tue, 15 Apr 2025 14:23:14 +0300
Message-ID: <Z_5BomVzAGFZ34oM@ark> (raw)
In-Reply-To: <CAJ7c6TOfQhE51Gf-=FeRgBTcUgznAcAA3Sa4mexi5MUg3ODj2Q@mail.gmail.com>
References: <Z_1Cq7JvabsFYjQo@ark>
	<CAJ7c6TOfQhE51Gf-=FeRgBTcUgznAcAA3Sa4mexi5MUg3ODj2Q@mail.gmail.com>

* Aleksander Alekseev <[email protected]> [25/04/15 13:20]:
> > I am considering starting work on implementing a built-in Raft
> > replication for PostgreSQL.
> 
> Generally speaking I like the idea. The more important question IMO is
> whether we want to maintain Raft within the PostgreSQL core project.
> 
> Building distributed systems on commodity hardware was a popular idea
> back in the 2000s. These days you can rent a server with 2 Tb of RAM
> for something like 2000 USD/month (numbers from my memory that were
> valid ~5 years ago) which will fit many of the existing businesses (!)
> in memory. And you can rent another one for a replica, just in order
> not to recover from a backup if something happens to your primary
> server. The common wisdom is if you can avoid building distributed
> systems, don't build one.
> 
> Which brings the question if we want to maintain something like this
> (which will include logic for cases when a node joins or leaves the
> cluster, proxy server / service discovery for clients, test cases /
> infrastructure for all this and also upgrading the cluster, docs, ...)
> for a presumably view users which business doesn't fit in a single
> server *and* they want an automatic failover (not the manual one)
> *and* they don't use Patroni/Stolon/CockroachDB/Neon/... already.
> 
> Although the idea is tempting personally I'm inclined to think that
> it's better to invest community resources into something else.

My personal take away from this as a community member would be
seamless coordinator failover in Greenplum and all of its forks
(CloudBerry, Greengage, synxdata, what not). I also imagine there
is a number of PostgreSQL derivatives that could benefit from
built-in transparent failover since it standardizes the solution
space.

-- 
Konstantin Osipov





view thread (30+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Built-in Raft replication
  In-Reply-To: <Z_5BomVzAGFZ34oM@ark>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox