31–40 of 63 posts
Earlier quoted context omitted.
Then new dev plans support hstore: https://postgres.heroku.com/blog/past/2012/4/26/heroku_postg...
I need a bit more than the approx 5MB of data - much more, but currently less than 20GB. I'm kind of in a no-mans land of Heroku data plans - until today!
Will be interesting to see what Heroku ends up rolling out for the higher-priced dev database (comparable to the current 20 GB plan).
They've said they'll release something "at a comparable price point" to the $15/month shared plan. Hopefully the $50/month database isn't it as that seems high for hobby projects that outgrow the small dev database.
Earlier quoted context omitted.
I need a bit more than the approx 5MB of data - much more, but currently less than 20GB. I'm kind of in a no-mans land of Heroku data plans - until today!
I'd love it if you used the new dev plan for your staging/dev db needs. This can help us drive the final limits.
Earlier quoted context omitted.
They've said they'll release something "at a comparable price point" to the $15/month shared plan. Hopefully the $50/month database isn't it as that seems high for hobby projects that outgrow the small dev database.
Crane is not intended to be the plan that will fill the role of the existing $15/mo database. We're still working on that one.
Can somebody clarify which heroku plans are best, as you work from development through MVP and initial traction? My current understanding is: Development Stage: Use the free plan. MVP Stage: When I have an MVP that I'd like to show people and get feedback on, I'm not sure if I should stay with the free plan, or if I need a paid plan at this point. Gaining Traction: Still low overall volume, but consistent users. What…
Use something like New Relic to watch your app's performance. If it's exceeding tolerable limits, you need to change something. This might be a re-write of your code to reduce load, or pouring more resource into dynos, workers, database or caching.
Earlier quoted context omitted.
Surely designing with the eventual migration in mind will reduce the pain in the end, though.
I am actually going through this right now as we saw our EC2 instances start doing 2-10 second response times under little load. So currently migrating to a dedicated server. What is is found an interesting product called VCider which allows you to create mini private clouds. This might be something to look into using from day one to help with eventual migration. It is free up to 8 servers.
Heroku is really great to get your started if you don't want to worry about managing infrastructure. However, you're paying a major premium for that and you need to have an exit plan from the beginning incase you grow too big and the costs no longer make sense.
I agree with everything you said, except that I don't think you need to spend any time working on an exit plan until the day you realize you're paying "too much" (whatever that means to you) for the benefit you're receiving from their managed hosting. I recommend: Launch on Heroku. Reevaluate that choice on success.
Think about what "too much" Heroku spend is. Think about what level of adoption/success it will take to reach that much Heroku spend. Then consider if you actually get to that level of adoption, are your Heroku costs really going to be "too much?" Don't spend more than 90 minutes on the whole exercise.
My guess is that, for most apps, worrying before launch about migrating off of Heroku is a premature optimization.