I am a mere small fry employee at Heroku. I nearly exclusively work on the efforts concerning Postgres. If you stopped using Heroku's product because you thou

I am a mere small fry employee at Heroku. I nearly exclusively work on the efforts concerning Postgres. If you stopped using Heroku's product because you thought it would not pragmatically meet your needs: I'm all for that. However, by description, it seems though you were more unhappy with the handling of the situation than the quantitative implications to an application. So, I'd like to expand on that line of inquiry: I'd like to think that trying to expose the implementation problems at Heroku would allow for more well informed decision making (e.g. what is the problem, how severe is it, what barriers exist to fix it, how long might it reasonably take to improve things, how can it be mitigated in the meanwhile) rather than being seen as only apologetics. I realize the point of Heroku is to abstract a lot of detail, but all abstractions are leaky, and it seems like people might want to know more, especially as ongoing experimentation yields information. I don't personally feel an opaque mea culpa is the most useful way to go about this. Do you disagree? Is there some other path you would have thought better overall, or in all respects altogether? In general, I compare this to the many support requests I have responded to over time about things Postgres does not do, or could do better, and (very roughly, unless already committed) how likely it would be that they would receive attention in a semi-near-future release. Generally, people seemed happy to be informed of that, but the dynamic is very different there. Nevertheless, it's the closest thing I've got in my immediate experience.