Personally, the only terrifying thing about this is that when Heroku releases something, it's been in the works for a good long while, and they usually have a stream of incredible releases waiting right behind it. The mind boggles at what they're going to be doing next.

But we'll be first in line for it :)

This is my biggest pain point while working with heroku.

I own a SequelPro license (as well as licenses for a couple of other non-free tools, RazorSQL and Querious) and I always come back to DBVisualizer.

It's open source, so nothing's stopping anyone from adding support for other SQL servers.

(Disclaimer: I haven't been involved much with SP for almost a year now, so possibly there has been progress in that time)

Thanks for everyone's support.

I worked on and almost launched an open source bounty site a couple years ago. But the closer I got to launch the more I realized that I hadn't adequately solved all of the hard UX problems (mostly around a: picking who's going to work on it, trying to avoid both having two people separately do it due to know central coordination and having one person say "yeah, I'm going to do this!" and then not get around to it and hold the project back, and b: how to handle it when someone does technically address the bounty, but in a way that is unsatisfactory either because bounty-placers did not perfectly state their needs or because of poor quality.

Disclaimer: I actually like pgAdmin3, especially the visualized explain page.

Nice job Heroku.

It's not clear from the pricing page, and I'm assuming it's per month, in which case it's reasonable, especially given the value added services being offered, especially the ability to fork the database and the automated creation of read slaves.

It looks like a solid offering. It's probably not right for companies that are subject to HIPAA or PCI compliance requirements, and there's no information on the use of compiled extensions in the db which may limit it's utility if you're wanting to use PostGIS or other specialist datatypes.

The advanced Postgres datatypes are pretty much my favorite thing in the world. We use HStore internally all over the place, as well as some more exciting projects that we haven't said too much about yet. As I mentioned elsewhere in the thread, if you're interested in trying out some of those extensions, contact me directly.

I am curious as to whether you do pro-rated pricing?

Ronin = Small Instance: 1.7 GB of memory, 1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit), 160 GB of local instance storage, 32-bit platform. ~$60/month spot.

Fugu = High-CPU Medium Instance: 1.7 GB of memory, 5 EC2 Compute Units (2 virtual cores with 2.5 EC2 Compute Units each), 350 GB of local instance storage, 32-bit platform. ~$120/month spot.

Ikea = Large Instance: 7.5 GB of memory, 4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each), 850 GB of local instance storage, 64-bit platform. ~$240 / month spot.

Zilla = High-Memory Extra Large Instance: 17.1 GB memory, 6.5 ECU (2 virtual cores with 3.25 EC2 Compute Units each), 420 GB of local instance storage, 64-bit platform. ~$360/month spot.

Baku = High-Memory Double Extra Large Instance: 34.2 GB of memory, 13 EC2 Compute Units (4 virtual cores with 3.25 EC2 Compute Units each), 850 GB of local instance storage, 64-bit platform. ~$720/month spot.

Mecha = High-Memory Quadruple Extra Large Instance: 68.4 GB of memory, 26 EC2 Compute Units (8 virtual cores with 3.25 EC2 Compute Units each), 1690 GB of local instance storage, 64-bit platform. ~$1440/month spot.

I think Heroku will pay less than the spot price for the raw server, but fork out bandwidth, storage, EBS IO, backups and so on. Amazon sells its basic servers cheap, but virtually nothing is included.

It looks like their margins go up at Zilla, but maybe the high-RAM instances need more bandwidth and backups.

I looked for any more documentation about that, but the only official word I have from them in the past is the support ticket I filed last year stating that they don't support "additions" like user defined functions or the various contrib modules.

Unfortunately, Postgres makes it difficult to install extension modules without superuser. That said, we've wanted to support contrib modules for ages. Lately, encouraged by the work Dimitri Fontaine has been doing on extensions, we have a pilot project going which includes support for hstore, pgcrypto, pg_trgm, and of course, postgis. Feel free to contact me at pvh(at)heroku.com if you're interested in taking it for a spin.

I don't use postgres - I hope heroku expands this kind of service to more databases (although I don't think it's likely in the near future).

The smallest database is also pretty expensive. I wouldn't mind a cheaper plan for less resources.

Only being able to create one database of each size is just weird, especially if forking or following. Can anybody confirm that this is a limitation? (I only read about this from one of the other comments here)

We hear you on the cheaper plan; watch this space.

Last, there is no restriction on creating only one database of each size.

Is there some technical reason that you can't offer both?

Presumably, their decision to only support Postgres is partly competition (many others provide MySQL on EC2), and partly technical. How would you justify the technical merits of the decision, without sounding "like a used car salesman"?

Those are the specific features I think that make Postgres a better choice for both use as my day-to-day database and why we chose Postgres over MySQL for building a database service.

Certainly you could build a similar service on top of, say, RDS, but without the features listed above, I think it would take a lot more work and not come out as well.

Hope that helps.

I do agree about them being expensive. Their services in general are too expensive for me -- personally I prefer to manage my own EC2 instances. But they do provide value worth paying for depending on your needs.

That said, yes, EBS can have unstable performance. We monitor for several kinds of related problems and in the most dire of straights can perform a hardware migration to a quieter node which generally clears issues up.

I'm sorry, but daily backups are not only for high availability, but also for point in time recovery.

What if $dev drops the user table by mistake ? Do they provide backup for that ?

From https://postgres.heroku.com/#protect : "Every change to your data is written to write-ahead logs, which are shipped to multi-datacenter, high-durability storage. In the unlikely event of unrecoverable hardware failure, these logs can be automatically 'replayed' to recover the database to within seconds of its last known state."

I think the question is whether the customer will be able to perform a point in time recovery, and what the size and resolution of the backlog is.

* What do I do if I need to tune/configure Postgres for my workload.

* How is the performance of transferring all of the queries and responses across the internet?

Keep in mind I've never used postgres before so these may be moot points.

Performance depends on where you are querying from. We've found that if you are inside EC2 network overhead is typically <1ms.

http://www.postgresql.org/docs/9.0/static/ddl-schemas.html

I guess I'm probably one of like three users of PL/python, especially since it's untrusted. Worth a check, though!

Trusted languages are far more likely. This one looks really, really cool: http://code.google.com/p/plv8js/wiki/PLV8

(edit to add: this is mysql-only, unfortunately :) I forgot about that part when I remembered it off-hand.)

In order to reduce this ambiguity we are gradually moving towards placing user apps on a different domain; because we approach these kinds of issues very gradually this will probably take quite some time to fully complete, but as of today all new Cedar stack applications are hosted on herokuapp.com.

And confused by "one database only". Does that mean CREATE DATABASE databases? If so why?