Heroku's new $50 and $100 per month database plans
postgres.heroku.com
postgres.heroku.com
While paying 3.3 times more[2] may be ok for the added simplicity, you have to wonder if your 'dedicated' database is really just a small instance on EC2? If it is a larger instance, then you are sharing it with other users.
However, even a small instance is far from not being shared. EC2 has performance issues, especially small instances. Disk IO is the worst.[3]
Disclaimer: These are all just my observations, and I don't how Heroku actually configure their Ronin databases. I'd love to be proven wrong, and to have someone from Heroku explain. But from personal experience with both EC2 and Heroku's Ronin database, if my conclusions are wrong, the results are not. I've seen very slow performance on the simplest of queries on both configurations.
[1] http://aws.amazon.com/ec2/instance-types/ [2] http://aws.amazon.com/ec2/pricing/ [3] http://www.frederico-araujo.com/2011/12/27/why-ec2-still-sux...
Heroku/EC2 are fantastic for what they are but quite pricy.
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.
I think the people who are most likely to worry up front about a plan for migrating off of Heroku has a great deal of overlap with the sort of people who will make migrating off Heroku difficult for themselves by depending on too many "exotic" add-ins.
The most obvious example (and probably most relevant) is that on Heroku you can't store permanent files locally. Instead you need to store them on something like Amazon S3. However, the application servers also aren't a great place to do things like video processing. Instead, you'd lean on a third-party service like Zencoder.
As a result, applications that run well on Heroku have very few environmental dependancies and migration should be relatively straight forward. They even make it brilliantly easy to dump your database to a file that can be imported elsewhere.
I think the real pain in migrating from Heroku is outside of the application itself. I think the real pain is duplicating all the infrastructure and staffing you never had to think about when you deployed your app in the beginning. Honestly, I don't even know all the details of what they do. But I know I've never set it up myself and I'm not really interested in doing it. I don't want to hire someone to do it, either. It's enough being on call for application issues, never mind all the rest.
In every venture I'm involved in, traffic and users translate directly into money, so paying Heroku a cut of that success is not a problem. They've earned it.
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.
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 is the cheapest paid plan that works for this stage? Is it the $15 plan, or the $50 plan?
Increasing Traffic: At this point, it's a little more clear that you choose add-ons to match your specific needs.
I would love it if someone could clarify what kinds of loads each of these plans could reasonably be expected to handle.
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.
Can we create Crane followers of a larger master database yet? That would be really useful - keeping a cheap, eventually-consistent replica around for backup and analytics.
I'm building an app that will eventually use hstore for data. I say 'eventually', because I'm currently using serialized columns on the $15/month shared plan, and hstore is not yet supported.
At $50/month, this is cheap enough for me to use as a staging server or as a pre-release server to get hstore across my entire environment.
I'm kind of in a no-mans land of Heroku data plans - until today!
But what is the use case for a dev databases with 'much more than 5MB of data' ?
My dev machine has a much smaller set of data, but on Heroku, I run stage servers with reasonable amounts of real life data that I need for final testing
PostGIS has been available on Heroku's dedicated DBs (https://devcenter.heroku.com/articles/is-postgis-available), but the $200/month was a bit high for early stage. $50 is much more manageable and I might be looking towards Postgres + PostGIS in the future… (assuming that the linked post also applies to these new plans)
With that said I'm not sure how squid managed to be more dangerous than a kappa. >Kappa are usually seen as mischievous troublemakers. Their pranks range from the relatively innocent, such as loudly passing gas or looking up women's kimonos, to the malevolent, such as drowning people and animals, kidnapping children, and raping women
~wikipedia
The best gift is cucumber, which the Kappa can't resist. Don't go swimming in Japan after eating cucumber, because they will drown you when they smell it on you.
https://devcenter.heroku.com/articles/migrating-data-between...
I ended up going with the clearDB addon just to save learning time, but at $10pm for only 1GB it's definitely a worse plan than the $15pm 20GB postgresql database you offer.