Add a Heroku Postgres Eco Tier

[dunkmann00]

Required Terms

• [X] I agree to follow this project's Code of Conduct
• [X] I have read and accept the Salesforce Program Agreement

What service(s) is this request for?

Postgres

Tell us about what you're trying to solve. What challenges are you facing?

The switch to Heroku Eco dynos seems to be a nice compromise between free and paying $7/month for each app you have. This is especially true when the app(s) is for prototypes/staging/personal usage. For me personally, I can easily stay within the Eco tier limitations for the few personal apps I run for myself and am happy to spend $5 for what Heroku is providing.

However, when it comes to using a database, the pricing is not as "friendly". Since using a DB is basically a necessity, especially when using Heroku because of the ephemeral filesystem, this essentially means each app costs an additional $5. In this case, for me personally, this doesn't seem worth it. When I'm storing 100s of rows, < 50MBs of data, and really only running the dynos the database is attached to for < 15 hrs/month, it is difficult for me to justify to myself the $5/app price. It is difficult to justify because for each app I am running like this, I am barely using the DB resources I am paying for. But because it is a per app price, I end up having to buy another database plan and waste most of the available resources.

I don't know how many other people are in a similar situation as I am. But I would think there are various situations where it would be great to pool your database plan limits across multiple DBs, similar to how Eco dynos work. Rather than a pool of hours, you would get a pooled row limit, storage capacity, etc. This way each database would still be completely separate and conveniently attached to a specific app, but from Heroku's perspective users couldn't abuse DB usage like with the previous free tier offering. If the Mini plan's specs were used for an Eco database plan, that would work well for me. And if a particular DB got too big, I could then pay to bump it up to the "normal" tier where it has its own set of specs/resources, again similar to how Heroku has setup dyno plans.

I would love to keep using Heroku Postgres because it works well, I like that it is managed, and I don't mind paying for it. It just seems silly to me to pay for something that I am essentially barely using. I would personally rather pay a fixed cost for a plan and know that I can run multiple databases within its limits. For example, I find the idea of using DigitalOcean's Managed Postgres appealing because it doesn't cost more if I create more DBs. There are tradeoffs, but it is a very compelling option for my use case. If Heroku were to offer something like this, for me, the limits of the Mini plan are fine. I would be curious what others think about this. And I'm sure Heroku has data around how much of the DB limits people are actually using, so I would be curious what someone from Heroku thinks as well.

I realize this is only going to be useful for a certain group of people, like myself, who are not running anything big and are not generating any money with an app (if I was I wouldn't mind paying for that app). But I hope there are enough people that do fit this bill that it could be worthwhile for Heroku to look into and perhaps even offer!

Thanks!

[kouroubel]

I have the exact same problem. Besides my commercial apps which I do not mind paying the $5/month for, I have a bunch of staging apps which are idle most of the time and a couple of personal apps with minimal usage. For example, one of my personal apps is for a group of 15 friends so they can declare participation when we meet, once or twice a month. This is just 15 rows and no way does it justify $5.

The solution I have found is the following:

• Create a database dump and upload it to S3
• Remove the DB from the app when it is not going to be used
• When I want to use the app again, re-install the DB and restore the dump with heroku pg:backups:restore 'presigned URL from S3' DATABASE_URL -a appName

So far the above process works pretty well but it is a bit tedious.

Proposed Solution: An option to "park" our DBs so we are not charged for them. The process described above could be automated and offered as an option from inside the Heroku platform and/or CLI.

[dunkmann00]

Interesting! Thanks for describing how you have had to work with the new plans @kouroubel. The idea of "parking" the DBs does seem useful.

For me personally it isn't as necessary, since even with my staging apps the amount of rows/data would still probably fit within the shared limit for my personal apps. But I could see how for some use cases, like an app with many records, that could be very handy to only incur that when working on the staging app.

In your case, are the DBs that are for staging apps that you have been turning on and off as needed, are those for the personal apps you mention or the commercial apps?

[kouroubel]

The staging apps are in pipelines with commercial apps. I don't have staging apps for the personal ones...

[dunkmann00]

Hi @afawcett! I was just wondering if you had a chance to look at this? It seems you have been assigned this issue so I was curious if you had any thoughts about this? Or perhaps even just getting feedback if this is something that is potentially feasible for Heroku to do, or if it is highly unlikely that this type of pricing tier would be introduced? Really any type of feedback would be greatly appreciated.

Thanks!

[kreintjes]

Would be nice to have some sort of eco/autosleep option (similar to https://github.com/heroku/roadmap/issues/111) for both Postgres and Redis for review, development and staging apps.

[dstarner]

Hi @afawcett! I was just wondering if you had a chance to look at this?

I'm not Andrew, but I am an engineer who works on Heroku, this is a really great idea. More variation in pricing + usage across our dyno sizes and data plans is something that we are really interested in doing, so we appreciate the public encouragement for it! This is definitely something at the forefront of our minds as we keep improving the platform.

We are still working on extensions of some of the awesome work mentioned in today's 2022 Roundup blog post, but after that is done, we aim to work towards this increased variation.

[chillu]

We moved our review app databases to a shared CrunchyData database for this reason. Even with a dozen engineers and efficient review processes, we rack up 40+ concurrent review apps. They have virtually zero resource demands on either the dyno or the database.

[jbrown-heroku]

This is, indeed, welcomed feature as it seems and we have roadmapped it to be included with the new Heroku database platform we are currently building. We are imagining of a feature where the customer pays for storage but the compute will be in a "sleep mode" until certain event (maybe manually) to be woken. It might be slightly different from the OP, but would like to gather some feedback/thoughts.

Our target release date for this feature is mid 2025.