MIME-Version: 1.0
References: <Z_1Cq7JvabsFYjQo@ark>
In-Reply-To: <Z_1Cq7JvabsFYjQo@ark>
From: Aleksander Alekseev <aleksander@timescale.com>
Date: Tue, 15 Apr 2025 13:20:11 +0300
Message-ID: 
 <CAJ7c6TOfQhE51Gf-=FeRgBTcUgznAcAA3Sa4mexi5MUg3ODj2Q@mail.gmail.com>
Subject: Re: Built-in Raft replication
To: Konstantin Osipov <kostja.osipov@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAJ7c6TOfQhE51Gf-%3DFeRgBTcUgznAcAA3Sa4mexi5MUg3ODj2Q%40mail.gmail.com>
Precedence: bulk

Hi Konstantin,

> 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.

-- 
Best regards,
Aleksander Alekseev