[samk117]

I appreciate your response, but my point is this: people are going to go with the service that they can scale up from $5/month to $28,000/month without any interruptions or switching of providers. It would be great to see you guys try to tackle this problem with that in mind, and I think you could do it really well. I just think you underestimate how many people want their infrastructure to cost nothing when they are in pre-launch mode, and will let their pre-launch infrastructure dictate their post-launch.

To reiterate: I get that your service doesn't start to scale well until the $99/month price point, but I don't care about performance until I'm at that price point anyway. I'd rather have the ability to start from nothing with OK/crappy performance, then have to switch services right when my product starts getting traction. It's about continuity and scaling up from nothing.

[fizx]

> I just think you underestimate how many people want their infrastructure to cost nothing when they are in pre-launch mode, and will let their pre-launch infrastructure dictate their post-launch.

Somehow, given Craig's history at Heroku, I imagine he understands this better than any of us ;)

[doh]

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.

[ProblemFactory]

> 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.

[qaq]

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.

[doh]

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.

[chucky_z]

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.

[manigandham]

How many products actually start getting traction? How many of those then need to scale beyond a single node? How many of those running on a $5/month plan will it take to make up for the dev and support costs?

I'm sure they can easily scale their plan down to the $50/month range with smaller instances but they're a business too and having a cost cut-off makes sense. The companies that need the scale will find them regardless, and they have the Citus Warp product as stated in the article to make migrations easy.

[sam0x17]

Basically copy the low-end lineup of https://www.elephantsql.com/ and then once you hit $99/month switch it over to sharding / whatever

[sam0x17]

If the masses use your product, the whales will follow