есть другой продукт на основе ПГ, там что-то есть:
https://postgrespro.ru/products/postgrespro/enterprise

может это тогда?

это позволит приблизиться к решению оракла, но как принято говорить - больше похоже на "костыли")))

Это кластер HA. Наверное стоит уточнить ваши требования к кластеру)

ну уж лучше чем покупать оракл )))

в продолжение про PgPro Ent:
https://postgrespro.ru/docs/enterprise/9.6/multimaster

ну… RAC тоже в известной степени “костыли”…

Когда же народ поймёт, что мультимастер - это не про реляционные СУБД?! Когда перестанет хотеть это непотребство?

возможно. это то что я успел нагуглить и "погрузиться в краткое введение")))

спасибо

Ну почему же? CockroachDB с виду вполне реляционная, и при этом distributed ACID.
Т.е. "внутри" реляционной СУБД могут быть очень разные технологии, сама модель этому не препятствует.
Другое дело, что "традиционные" /  "обычные" RDBMS создавались не с этой целью.

можно и на Postgres-XL  тогда смотреть

он же умер вроде? Года два назад собирал его, он был так себе. CitusDB помоему сейчас претендует на эту роль

Нужно хорошо понимать, для чего вам нужен кластер.
1. Просто HA (если одна из нод вышла из строя, то чтобы система продолжала работать)
2. Масштабирование read-only нагрузки и  OLAP запросов
3. Масштабирование read-write нагрузки (OLTP запросы)

Для 1) Постгрес предлагает набор "Сделай сам" - репликация с помощью потусторонних тулзов (Патрони, Сталон, ...)
2) Можно сдедать с помощью той репликации (hot standby).
Но для OLAP лучше подходят специализированные решения типа CitusDB, TimescaleDB, GreenPlum или даже Postgres-XL. Для облаков есть Amazon RDS и Aurora.
Для того, чтобы выполнять на репликах read-only запросы надо их как-то уметь отделять от апдейтов. Это можно делать на уровне приложения или с помощью pgbpool/pgbouncer-rr.
Или же использовать pgpro:multimaster
3)  обязательно подразумевает шардинг - т.е. горизонтальное партицирование. Эффективнее всего это делать на уровне приложения. Но если не возможно или не хочется, то можно использовать CitusDB, pgpro:pg_shardman

Он сейчас поддерживается 2Quandarnt-ом.И вроде бы вполне живой.

ну как поддерживается. Все это напоминает больше "чтобы было". Большое отставание от ванилы, дырявая документация и очень нестабильная работа. Масштабировать чтение на нем очень проблематично, потому как с ростом коннектов он плодит большое количество соединений к data-node -ам. Тестировал в 2018 года 9.5 сборку от 2ndQ под один из продуктов. Вывод простой - для OLTP он не подходит.

Только насчёт 1) стоит учитывать, что даже синхронная репликация не гарантирует отсутствие потери транзакций при disaster, а насчёт 2) — что эта репликация не ACID (я лично видел, как на этом потеряли "немножко" денег, не перепроверив отчёт, например).
А уж 3) может принести ворох дополнительных проблем, даже если пользоваться помощью сторонних решений.

CockroachDB is a distributed SQL database built on a transactional and strongly-consistent key-value store.

И что? Опять-таки, неважно, что внутри. Вот PostgreSQL is built on a file system — что, это не RDBMS теперь? ;)
Кстати, из описания CockroachDB: "A relational database for next generation ..." и т.д.
А так, с виду — те же таблицы/схемы и т.п., и даже SQL. Т.е. что в ней не так?

> И что? Опять-таки, неважно, что внутри
Извините, но у меня противоположное мнение. Дискутировать по этому поводу желания не имею. Для этого надо иметь опыт "развлечений" с обоими СУБД, а у меня в активе - ПГ и мыскль.