Hacker News new | ask | show | jobs
by doh 3139 days ago
This is not a bad advice overall, but I think that Citus has still a huge market to conquer before they go down this path.

Single PG node can handle easily 80k/s writes and reads and store up to 3TB of data safely. Wast majority of companies will never have to think about cluster as this is more than sufficient for most.

No matter if it's Citus or any other DB, horizontal scaling comes at cost and most companies should pay it. Citus helps to the ones that really have issues with performance beyond those levels (like us) and I think the Citus team is smartly targeting those kind of customers, at least for the time being.

2 comments

> Single PG node can handle easily

I think that's exactly what people are asking for. A single PG node (or even a shared node) managed and monitored by competent people for a "hobbyist" price. You start your project on that, and when you outgrow it, click a button to upgrade to the real Citus Cloud.

Now it's entirely possible that the customer support and separate infrastructure maintenance doesn't make sense for Citus at hobbyist price points - but it would be a way for them to capture potential customers before they standardise on RDS, Redshift and other database scaling options.

3TB? even on crap option like RDS up to 6TB is OK. You can get generic box with 200+ cores (actual cores not vCPUs) and 12TB of RAM from SuperMicro.
You can go to as high as the box allows you to go (GCE allows I believe up to 10TB per server), but the performance will suffer.
I would add the caveat that it depends on your data heavily.

I supported a 20TB single-node DB, and it worked just fine. We had a lot of cold data though (about 10TB of it was solely for historical records, and 9.5TB of the rest was only accessed 4x yearly for massive reports).

The hardest part was never postgresql, mainly in numa related stuff.