[znpy]

> Our roadmap includes support for multi-master configurations, enhancing availability and fault tolerance. This will allow for read and write operations across multiple nodes, improving performance and resilience.

Fu--ing finally!

[oliverrice]

what's your use-case for multi-master that would not be supported by something like regional routed for read-replicas with high availability? i.e. do you have a specific need for low global write latency, or is it motivated by something else?

[znpy]

> do you have a specific need for low global write latency, or is it motivated by something else?

It's motivated by liking of reliable systems that keep working when a node fails.

There are a bunch of non-webscale companies that pick mysql over postgresql because they can use either percona xtradb cluster or galera cluster.

Having an open source multi-master solution would mean that postgresql could finally be used over there as well.

[akorotkov]

Thank you, your feedback is appreciated.

The important design issue about building active-active multi-master on the base of raft protocol is about being able to apply changes locally without immediately putting them into a log (without sacrificing durability). MySQL implements a binlog, which is separate from a log, to ensure durability. OrioleDB implements copy-on-write checkpoints and row-level WAL. That gives us a chance to implement MM and durability using a single log.

[oliverrice]

yeah, fair shout `columnar index` for hybrid analytical workloads and `multi-master` roadmap items haven't been put in an order on the schedule yet so maybe multi-master makes sense to do first. Both align with webscale requirements though. Columnar would move into the AlloyDB space and multi-master would be more like PlanetScale (although not quite the same audience in the latter case)