Привет, можно накидать мне postgres-compatible рдбмс, только чтоб были распределенные,

и с адекватной опенсорсной лицензией? Пока смотрю на yugabyte, но может есть что получше?

Citus, TimescaleDB

а есть опыт с ними? timescale кмк очень специализированный, у меня не большая нагрузка, и точно не time series, мне важнее надежность и возможность развернуться в геокластер

Т.е. распределённость в данном случае не шардинг, а скорее мастер-мастер?

да, хотя шардинг мне тоже не помешает. Наш софт умеет писать в постгрес-бекэнд, но рассчитан на edge так что желательно бекенд который я смогу размазать по планете

Нет, такого щупать не доводилось

Postgres, postgres pro и .... Enterprise DB, чёрд, и всё!

но оно ведь не геораспределенное как юга или кокроач

Работающего мастер-мастер на протоколе RBMS -- нет и не предвидится.

Ну вообще кокроач и спаннер. Но судя по тому, что мелькало (сам до сих пор не вчитывался, каюсь) - у них очень жесткие требования к сети (что неудивительно, учитывая что наверняка внутри данные лежат по разным шардам, каждый из которых должен рапортовать на каждую операцию, и онии должны очень оперативно синхронизироваться, чтобы все это вменяемо работало)

мне без разницы как именно он работает, мне важно чтоб апликация которая уже умеет цепляться к обычному постгресу, могла работать с данным бекэндом

Кукарача -- это жёстко прибитый шардинг, потому не классический мастер-мастер. Соответственно, со свойственными ему тормозами на синхронизацыю -- почти всегда сильнее чем в случае одного сервера. Кроме того, с консистентностью данных, которые зависят друг от друга между шардами там тожэ не слава богу.

Так невозможно не шардить же Иначе данные ограничены размером узла, и встает большой вопрос зачем вообще распределенка, если один из её ключевых бенефитов не работает

Там не только шардить -- там у шарда есть мастер, что сразу много к чему весёлому приводит.

Это тоже в общем-то нормальная практика, потому что это быстрее, чем собирать консенсус на каждую операцию

Быстрее или не быстрее -- это другой вопрос. Ключевое здесь -- что ни выборный консенсус ни такой тиранический консенсус практически не работают как "у нас есть несколько независимых мастеров, который близко к клиентам и вообще независимо их обслужывают, а потом обмениваются информацыей". Во-первых потому, что с вменяемой скоростью работает это только в локалке, ни о какой "близко к клиентам" и речи нет, во-вторых -- они все друг от друга зависят. Поэтому жэ работающие решэния такого типа это скорее крепко связанный кластер, чем мультимастер.