This is exciting:
> ...This log architecture is optimized for raft consensus-based replication allowing the implementation of active-active multimaster.
I'm a developer but manage 2 PostgreSQL instances each with an async replica. I also manage 1 three-node CockroachDB cluster. It's night and day when it comes to any type of ops (e.g. upgrading a version). There's a lot of reasons to use PostgreSQL (e.g. stored procedures, extensions, ...), but if none of those apply to you, CockroachDB is a better default.
I just finished interviewing someone who went into detail about the difficulty they're having doing a large scale migration or a mission critical large PG cluster (from one DC to another)..it's a multi-team, year long initiative that no one is comfortable about.
In my experience, PG is always the most out-of-date piece of any system. I still see 9.6 here and there, which is now EOL.
Raft doesn’t magically make a database multi master. It’s a consensus algorithm that has a leader election process. There’s still a leader, and therefore a single master to which writes must be directed. The problem it solves is ambiguity about who the active master is at the moment.
Right. The idea of active-active OrioleDB multimaster is to apply changes locally and in parallel send it to the leader. Then sync on commit and ensure there is no conflicts.
The design document will be published later.
Please have it subjected to a Jepsen test suite ASAP!
My thinking is since it's postgres wire compatible the existing tests should work?
Does Jepsen just run automated tests?