Heroku Postgres 2.0 | Hacker News Reader

Heroku Postgres 2.0

postgres.heroku.com

28 pointsjamesharker11 comments

Wow, talk about hiding the ball. Heroku Postgres 2.0 is changing the cost structure in a dramatic way. Gone is the 1TB of storage on all production plans (now the "standard" tier). Instead, you are limited to 64GB of storage on Heroku's cheapest $50/mo plan. As hoddez mentions above, you'll now need to spend $2000/mo to get the 1TB of storage space that you were able to achieve on yesterday's $50 plan.

What's additionally frustrating is they have made pricing much less granular. Instead of 8 pricing levels based on your ram requirements, you now only have 5. Old price points of $100/$400/$800/$1600 have all been eliminated and now you are stuck choosing between $50/$200/$750/$2000. These are steep price jumps between each level.

I understand that Heroku wants to highlight the new features here, but when they bury the pricing at the bottom of the post, and even include language like this:

"For those already familiar with our pricing our new standard tier is very similar to our now legacy production tier. For some of you this means migrating could actually provide over 45% in cost savings on your production database."

It strikes me as a bit disingenuous. For reference, here is the old pricing structure from the archive: https://web.archive.org/web/20131003031924/https://www.herok...

And here is Heroku's legacy pricing page: https://devcenter.heroku.com/articles/heroku-postgres-legacy...

All of the old prices still fully exist, in no way are customers required to choose the new plans. The new plans where there are equal specs are indeed lower in price in many places. We've documented all of the legacy plans within devcenter https://devcenter.heroku.com/articles/heroku-postgres-legacy.... If theres ways we can make this more clear then would love to hear about it at postgres at heroku.com.

In regards to the storage limits, this was put in place actually to prevent users from shooting themselves in the foot. We examined all current users in this process as well as connection limits and looked to what limits were used today, as well as when people were over certain thresholds for the other problems it created. As it exists today you would now hit these limits and have a clear understanding of why, versus other problems that previously arose as a result of having them so high.

Thanks Craig! I missed the legacy pricing page and edited my post to reflect this. To make this more clear and transparent, I would include a link to this directly on your blog post. It certainly would've helped me.

If you wouldn't mind me asking, why the removal of the Kappa/Fugu/Zilla price points in the new tiers?

Will absolutely make update the blog post to include the link, was simply an oversight in not having it there in the first place.

Would be happy to detail more on the reason for removing some of the other price points feel free to email me, craig at heroku.com

Silently dropped the storage drastically in the lower plans. Knew the 1TB at $50 a month was too good to last forever. Now for that much storage you need to pay $2000

yeah these changes price adjustments are getting too be too much. And now when I enter the New Relic console I get "login failed"... When I try to look at history in Adept I get a Rails error. It feels like their priority is NEW and MORE instead of SOLID, RELIABLE. Going to try AWS for next app.

Luckily, my Heroku apps are all RDS anyway so no paranoid scrambling here...

Could you raise a ticket for this stuff? Login problems with Add-ons isn't a common thing and we'd like to investigate.

I'll try to get around to it, sure. Adept isn't a log-on issue it's after I'm authenticated, just any time you hit "History" it Rails errors, sometimes works after a few refreshes.

I really want a better explanation of how 'rollback' works. You have to create a fork before you run your migration script so you can roll back to that fork?

Rollback is essentially like a fork to the past. It creates a new database, but only replays transactions up to a specific instant. It's based on the Postgres Point-in-Time Recovery feature: http://www.postgresql.org/docs/current/static/continuous-arc...

Rollback can be run at any point in time you do not have to create a fork ahead of time. We will be conducting some follow up posts explaining how the underlying mechanism works, for now you can read more on it at https://devcenter.heroku.com/articles/heroku-postgres-rollba...

Reply on news.ycombinator.com