3 ms·

Its great to see scale and progress, but being closed source is HUGE DEALBREAKER. Clickhouse is also on the right track of building some amazing opensource int

Its great to see scale and progress, but being closed source is HUGE DEALBREAKER. Clickhouse is also on the right track of building some amazing opensource integrations with postgres, they have superior*[1] managed postgres looks like from their recent blog. I hope they do some OSS sharded postgres solution. [1] - https://clickhouse.com/blog/benchmarking-nvme-managed-postgres-planetscale-vs-clickhouse https://clickhouse.com/blog/benchmarking-nvme-managed-postgr...

ahachete 21d ago
If you want an OSS sharded Postgres, just use Citus. Feature-full, proven, mature, boring.
- weekendcode 21d ago
  its not feature-full. like schema changes locking, coordinator node.. Maybe I am wrong, but I am yet to read stories on operating tens of TB scale workloads on citus.
  - saisrirampur 21d ago
    Most Citus workloads were 10s of TB with largest at around a few PB or so. Heap was a couple PB, back then, if I remember correctly. It is a brilliant piece of technology that supported mission critical workloads across mid/late stage startups to huge enterprises. The planner/executor are very advanced supporting a multitude of features and decade of intricate effort. The biggest problem of Citus was migration effort, transition from single node to multi-node was not trivial. Here I’m not talking about single table use-cases, more classic relational, multi-tenant apps with 100s to 1000s of tables. This is partly expected with most sharding technologies, though. Sharing some insights based on my multiple years of experience working with Citus! Here are few customer use-cases I could found: https://docs.citusdata.com/en/v10.0/get_started/what_is_citus.html?l#how-far-can-citus-scale https://docs.citusdata.com/en/v10.0/get_started/what_is_citu... https://info.citusdata.com/rs/235-CNE-301/images/Citus_Data_Case_Study_-_MixRank.pdf https://info.citusdata.com/rs/235-CNE-301/images/Citus_Data_...? https://www.youtube.com/watch?v=F6df3HV6kP0 https://www.youtube.com/watch?v=F6df3HV6kP0
  - ahachete 21d ago
    > schema changes locking Schema changes need locking... everywhere. Citus is no different. And they need proper design everywhere. If you mean that it requires distributed transactions, well, yes, again: expected and solved. Not even all sharding solutions support this. > coordinator node Not sure what the problem is here. If what you mean is that a single coordinator, even with an HA replica, can saturate, that's true, but you can add multiple "query routers" (that's our name in StackGres, see [1]). > Maybe I am wrong, but I am yet to read stories on operating tens of TB scale workloads on citus. For example, we have a customer that ingests some 30TB/day, and it's ramping up towards 200TB/day of ingestion. On 24 worker nodes. [1]: https://stackgres.io/doc/latest/administration/sharded-cluster/citus/#query-routers https://stackgres.io/doc/latest/administration/sharded-clust...
saisrirampur 21d ago
Sai from ClickHouse here, I lead the Postgres efforts at ClickHouse. Expect news from us on this soon! Many of us here are ex-Citus and have done this for Postgres before.

ahachete 21d ago

If you want an OSS sharded Postgres, just use Citus. Feature-full, proven, mature, boring.

weekendcode 21d ago
its not feature-full. like schema changes locking, coordinator node.. Maybe I am wrong, but I am yet to read stories on operating tens of TB scale workloads on citus.
- saisrirampur 21d ago
  Most Citus workloads were 10s of TB with largest at around a few PB or so. Heap was a couple PB, back then, if I remember correctly. It is a brilliant piece of technology that supported mission critical workloads across mid/late stage startups to huge enterprises. The planner/executor are very advanced supporting a multitude of features and decade of intricate effort. The biggest problem of Citus was migration effort, transition from single node to multi-node was not trivial. Here I’m not talking about single table use-cases, more classic relational, multi-tenant apps with 100s to 1000s of tables. This is partly expected with most sharding technologies, though. Sharing some insights based on my multiple years of experience working with Citus! Here are few customer use-cases I could found: https://docs.citusdata.com/en/v10.0/get_started/what_is_citus.html?l#how-far-can-citus-scale https://docs.citusdata.com/en/v10.0/get_started/what_is_citu... https://info.citusdata.com/rs/235-CNE-301/images/Citus_Data_Case_Study_-_MixRank.pdf https://info.citusdata.com/rs/235-CNE-301/images/Citus_Data_...? https://www.youtube.com/watch?v=F6df3HV6kP0 https://www.youtube.com/watch?v=F6df3HV6kP0
- ahachete 21d ago
  > schema changes locking Schema changes need locking... everywhere. Citus is no different. And they need proper design everywhere. If you mean that it requires distributed transactions, well, yes, again: expected and solved. Not even all sharding solutions support this. > coordinator node Not sure what the problem is here. If what you mean is that a single coordinator, even with an HA replica, can saturate, that's true, but you can add multiple "query routers" (that's our name in StackGres, see [1]). > Maybe I am wrong, but I am yet to read stories on operating tens of TB scale workloads on citus. For example, we have a customer that ingests some 30TB/day, and it's ramping up towards 200TB/day of ingestion. On 24 worker nodes. [1]: https://stackgres.io/doc/latest/administration/sharded-cluster/citus/#query-routers https://stackgres.io/doc/latest/administration/sharded-clust...

saisrirampur 21d ago

Sai from ClickHouse here, I lead the Postgres efforts at ClickHouse. Expect news from us on this soon! Many of us here are ex-Citus and have done this for Postgres before.