Live data from Hacker News

Why companies move off Heroku (besides the cost)

blog.porter.run

171–180 of 230 posts

Re: Why companies move off Heroku (besides the cost)

#171

Warning: There are a couple people in this thread mentioning products that they're investors in. I won't call them out expressly, but I think people should be direct about their incentive alignments. It's disingenuous and borders on astroturfing IMO. Background: Founder of Railway.app here. There's a lot of these companies popping up that offer a "Heroku replacement", and once you dive in, you realize you have to pay…

Personal criticism of Railway: every time I emailed Railway to request to be unsubbed from the newsletter and my account fully deleted without a trace no one ever replied (the unsubscribe link in the newsletter was broken). It left a really sour taste in my mouth.

Re: Why companies move off Heroku (besides the cost)

#172

Earlier quoted context omitted.

I don’t like this either. I think maybe people are more used to this in the US, but I personally think that if you can’t be objective you need to be more humble in your communication. … of course Coke can trash-talk Pepsi and vice-versa… but if I’m making a technical assessment of competing products or software platforms I get a bad feeling of anyone using those sales tactics.

Yeah, but who we protecting? Don't readers want a rigorous debate? Are we pirates or diplomats?

In Germany there are, for examples, rules regarding comparative advertising. Way stronger than anything the US has. Therefore we are not used to competitors trash talking other brands in ads.

So I am in the same boat when it comes to SEO/content marketing like this. It is advertising, nothing more.

And personally, when evaluating products, I agree with OP. I also like the people behind a product to be a bit more humble when comparing themselves to competitors.

Re: Why companies move off Heroku (besides the cost)

#173

Warning: There are a couple people in this thread mentioning products that they're investors in. I won't call them out expressly, but I think people should be direct about their incentive alignments. It's disingenuous and borders on astroturfing IMO. Background: Founder of Railway.app here. There's a lot of these companies popping up that offer a "Heroku replacement", and once you dive in, you realize you have to pay…

Your pricing page is confusing and I can't find enough details about the offerings.

1. What happens if i exceed the outbound bandwidth quota? 2. In Team, what is "seat" ? Also pricing number of team members is a bit of a turn off. I don't expect that kind of pricing from an infrastructure company. 3. What if I need more than 100GB disk in developer plan? 4. The postgresql offering - Does it offer failover, replicas, PITR etc? 5. How are logs handled?

Re: Why companies move off Heroku (besides the cost)

#174
post #79

Earlier quoted context omitted.

I think the most interesting part of this is the PaaS disaggregation. Heroku built an exceptionally good Postgres service. They could not have done that with multiple DBs. Even their redis is pretty meh. People like us (Fly.io) will end up either building very mediocre DB offerings or collaborating with DB companies (like yours: https://www.crunchydata.com/products/crunchy-bridge/ ) to ship stuff that's substantially…

Oh thanks for the props Kurt. The idea of PaaS disaggregation is definitely something I've been pondering for a bit and think I'm on the same page. At Heroku we were very opinionated about only Postgres for the longest time. We were fortunate to build-out the add-on ecosystem to give you more options, and explicitly did not want to run them ourselves for the longest time. I'm not sure how lucky we were vs. good, but…

genuinely curious - this is the first time im hearing of crunchydata in a "versus RDS" context. is there a pricing and feature comparison for RDS vs Crunchydata ? a honest tradeoff comparison.

Re: Why companies move off Heroku (besides the cost)

#175
post #165

Earlier quoted context omitted.

What do you mean? RDS lets you run replicas

RDS will manage replicas for you. But you can't run your own non-rds replicas.

correct. RDS does not even let you do a true, vanilla postgres backup to s3. the lock-in is complete

Re: Why companies move off Heroku (besides the cost)

#176

As someone that was there at Heroku after the acquisition, I don't think you can state that since the acquisition it's been consistently downhill. There isn't much debate that things have stagnated in the last 5-7 years which is a longer story on why probably. Some examples of innovation that happened and were launched after the acquisition: buildpacks (at the time of acquisition Heroku was still Ruby only), Heroku P…

> at the time of acquisition Heroku was still Ruby only Uhhh... I don't think that's true. There were 3rd party buildpacks available.

(Another ex Heroku person here)

At the time of acquisiton (Dec 2010) the Bamboo stack was the only GA stack, Cedar was in beta which used buildpacks internally but custom buildpacks didn't come to 2012 https://blog.heroku.com/buildpacks

Re: Why companies move off Heroku (besides the cost)

#177
post #131

Earlier quoted context omitted.

I'm curious about what "substantially better than RDS" means. RDS has been good enough for me for quite a while. Does it only matter once you get to a certain scale?

RDS runs pretty well! It's just irritating to use. The good DBaaS give me a lot more power. This is true for Heroku PG, PlanetScale, Supabase, and Crunchy Data. Some of them let me fork a DB to run a PR against, some give me app level features that save me code, etc. Most modern hosted DBs also let you run your own replicas. I'm not really complaining about how well RDS works when your app is connected to it and it d…

we’re using aiven.io and quite happy, although hard for me to compare. you can port across clouds, which is reassuring if we need to switch. Otherwise their support was helpful debugging a couple of db issues (in our own code). Wonder how they compare in this matrix if anyone knows?

no affiliation. just a customer.

Re: Why companies move off Heroku (besides the cost)

#178

A good article, except for one big thing: this is not an end user, rather a direct competitor. Public articles that criticize competitors always run me the wrong way. I haven't used Heroku in a few years, but it has served (using the Hobby plan) as a really low cost way to host web apps. I have been reading through the comments on alternative providers, and even though I haven't used it, GCP's Cloud Deploy looks inte…

Dosen’t criticising competitors increase competition? “We taste better than x”, “we have higher quality than x”, “we’re like x but cheaper?”

That can be true, especially for objective facts, but I would expect such criticism to be biased to the point of unreliability - "We taste better than x (according to our staff)", "we have higher quality than x (at double the price)", "we’re like x but cheaper (and we have nearly 20% of their features)". And even then, as an input there can be value, but it's helpful to at least know that it's coming from a competitor so I can anticipate the bias.

Re: Why companies move off Heroku (besides the cost)

#179

Earlier quoted context omitted.

Craig here from Crunchy the company he's referring to. Not sure what he has in mind, but having built a lot of Heroku Postgres in the early days I definitely have thoughts on what can make a database great. There is a big gap between most developers and what you need to know to efficiently run Postgres. Without tipping too much of our hand, we're focused deeply on building an amazing developer experience for Postgres…

disclaimer: former Heroku person here too Some examples of the things I've missed around developer experience for a database, that Craig and the team made possible at Heroku Postgres, include: - fork: ever had one of those "why does this bug only exist in production?" problems? It was so trivial to fork the DB and run your tests/hypothesis/whatever without the risk of actually impacting production. Same thing for _re…

> - fork: ever had one of those "why does this bug only exist in production?" problems? It was so trivial to fork the DB and run your tests/hypothesis/whatever without the risk of actually impacting production. Same thing for _really_ testing a migration script or load test.

This sounds great! How does it work though? Is it using some special postgres feature or btrfs snapshots or something else completely?

Re: Why companies move off Heroku (besides the cost)

#180
post #165

Earlier quoted context omitted.

RDS will manage replicas for you. But you can't run your own non-rds replicas.

correct. RDS does not even let you do a true, vanilla postgres backup to s3. the lock-in is complete

You can easily use pg_dump to do a "vanilla" backup to s3. Its a managed db service but if you wanted to run your own you can extract your data and move to a new db. The lock is not "complete" you are acting like you can't even extract your data.
Post reply on HN