MIME-Version: 1.0
References: <Z_1Cq7JvabsFYjQo@ark>
In-Reply-To: <Z_1Cq7JvabsFYjQo@ark>
From: Kirill Reshke <reshkekirill@gmail.com>
Date: Mon, 14 Apr 2025 22:44:32 +0500
Message-ID: 
 <CALdSSPgzhXTsY4UF-S2AsJwVBMvTSn1sB+Lc9jOcnQ8x3ebktg@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/CALdSSPgzhXTsY4UF-S2AsJwVBMvTSn1sB%2BLc9jOcnQ8x3ebktg%40mail.gmail.com>
Precedence: bulk

On Mon, 14 Apr 2025 at 22:15, Konstantin Osipov <kostja.osipov@gmail.com> wrote:
>
> Hi,

Hi

> I am considering starting work on implementing a built-in Raft
> replication for PostgreSQL.
>

Just some thought on top of my mind, if you need my voice here:

I have a hard time believing the community will be positive about this
change in-core. It has more changes as contrib extension. In fact, if
we want a built-in consensus algorithm, Paxos is a better option,
because you can use postgresql as local crash-safe storage for single
decree paxos, just store your state (ballot number, last voice) in a
heap table.
OTOH Raft needs to write its own log, and what's worse, it sometimes
needs to remove already written parts of it (so, it is not appended
only, unlike WAL). If you have a production system which maintains two
kinds of logs with different semantics, it is a very hard system to
maintain..

There is actually a prod-ready (non open source) implementation of
RAFT as extension, called BiHA, by pgpro.

Just some thought on top of my mind, if you need my voice here.

-- 
Best regards,
Kirill Reshke