Heroku Postgres: SQL Database-as-a-Service

http://postgres.heroku.com/

by tilt • 15 years ago

112 57 15 years ago

postgres.heroku.com

esja• 15 years ago

Cheapest plan: $200/month. That seems a bit high... what competes with this?

bdotdub• 15 years ago

When you think about all the setup, SysAdmin stuff, backups, scaling, etc you'll avoid, $200 a month ($2.4k) is pretty cheap to be able to just switch a scalable db on at a moments notice.

jbigelow76• 15 years ago

$200 is cheap but I'm hoping they eventually put out an option closer to the $40/mo price point just so I can play around with Postgre (I'm currently a MS SQLServer guy that wants to start branching out). I don't want to spin up a new AWS and waste time with configuration and other things and don't want to worry about hosing a currently running instance just to have a new sandbox to play in. I'd pay a reasonable amount to have something akin to a cheap "test" instance in exchange for giving up things like an SLA or dedicated support.

salsakran• 15 years ago

http://aws.amazon.com/rds/

I believe Heroku used EC2 under the hood before the Salesforce acquisition.

Whether postgres (vs MySQL), the polish and better ui/workflow of heroku is worth the premium over RDS depends on you.

mcs• 15 years ago

Heroku dynos are still ran on EC2 instances, exclusively on the East coast of the US.

I'm not sure if these postgres servers are. However one interesting note is that the "maximum database size" of the heroku server is 2TB, while RDS is 1TB.

absconditus2• 15 years ago

Seems high compared to what?

jhaile2• 15 years ago

Seems high compared to the cost of a comparable EC2 node. Of course - you avoid the administrative costs. But it's pretty expensive for an early-stage startup. Possibly a good deal for a larger company, but at that point you might prefer to just configure the EC2 nodes, backups, etc. yourself and save a good bit of $ every month.

thibaut_barrere2• 15 years ago

It's some money but I'm definitely interested. Scroll down and you see some interesting things:

- fork of databases (looks great to try out migrations easily)

- read-only asynchronous replicas

- connection from EC2 or elsewhere

- health checks and "continuous protection"

Looks fairly solid at first sight.

1gor• 15 years ago

   what competes with this?

http://xeround.com is a separate DB service, also heroku plugin. It is MySql-compatible, apparently they've wrote a custom distributed engine. Its is located on AWS or rackspace, so latency is quite low.

Since xeround is pay-as-you go, if your initial DB requirements are low, you can run it on something like http://fluxflex.com (which heroku-like PaaS, also AWS-based) and have 10 db-backed apps for something like $3 per month that will scale up when needed.

modoc2• 15 years ago

I've seen a lot of "Cloud" database services lately, and while I love the general idea, from what I've seen in real life, for any serious db use, the impact of network latency is a HUGE problem. So unless this service happens to be residing in the same data center as your application it doesn't seem like a viable option.

The difference between a local DB with <2 ms latency to a remote DB with ~50 ms latency is huge. I've seen application start times go from 1-2 minutes to 20-30 minutes by pointing at a remote DB.

So if your app is even somewhat DB intensive, you really need <2 ms latency to your DB, and if it's not DB intensive, you probably don't need all the scaling and other infrastructure strengths these services bring to the table.

michaelbuckbee• 15 years ago

I think you are correct.

I'd guess that the major target of this would be applications already running on AWS (which would put them mostly in the same datacenter). Obviously, a bunch of caveats about availability zones, etc.

joshu2• 15 years ago

I think this is enormously exacerbated by roundtripping. Even if it's just 2ms away, and you go back and forth a few dozen times, you are doing a ton of waiting.

This is one of the problem with joinless NoSQL databases, as well, since you HAVE to roundtrip to join.

randomdata2• 15 years ago

You don't have to. For instance, in CouchDB, you can use view collation to retrieve related documents in a single request.

misterbwong• 15 years ago

I tend to agree with this sentiment, though for some read heavy applications you can mitigate this problem via a distributed cache layer in your web tier.

bgentry• 15 years ago

Given that these databases run in AWS, there's no reason you can't run your application in the same datacenter.

milkshakes• 15 years ago

well, except that AWS doesn't let you coordinate AZ's between customers [1]

[1] http://aws.amazon.com/ec2/faqs/#How_can_I_make_sure_that_I_a...

aurynn• 15 years ago

Well, Postgres can shine here if you can do a fair amount of processing inside of a stored procedure. The sproc takes care of lifting, the client can be (fairly) limited in the transformations it applies, and the network latency of repeatedly going to the DB is lessened.

This is, naturally, very application-dependent.

einhverfr5• 15 years ago

Indeed, you can do a fair amount of processing without even hitting stored procs in Pgsql. Plain SQL gives you tremendous power in Pg. I find stored procedures add useful semantic sugar around these, but especially with newer versions things like common table expressions, arrays of tuples, and the like, gives you tremendous power.

eftpotrm3• 15 years ago

Not just Postgres; any database server in which you can do either stored procedures or submit arbitrary batches of SQL statements rather than just individual queries will let you do this. I routinely do in MS SQL Server, for example, and have worked on multiple projects where the ability to do this was utterly critical to overall performance.

To be perfectly honest, I'd consider any database server where I couldn't do this to be something of a toy because of the restrictions it places on overall app performance. It might be OK in SQLite or Access but a real database? Sorry, no, come back when you've finished the thing please.

eftpotrm3• 15 years ago

Pardon me, but if an app's operations time will go from 1-2 minutes to 20-30 by changing from a local to remote DB then you've either got an utterly abysmal network or enormously too many round trips to the database and the app could benefit hugely from being rewritten to move critical functions to running in SQL directly on the database server.

Now, I'd still rather have a local database but if you do that properly then almost all pages in your typical webapp shouldn't require more than a single round trip. IMHO.

modoc2• 15 years ago

FWIW: Remote DB was ~50ms away. Large scale eCommerce applications tend to be DB heavy-ish. Have a complex catalog structure with a few million SKUs, add in a few tens of millions each of users, orders, coupons, and push thousands of orders an hour, and you have a LOT of DB traffic. Add in things like real time inventory checks on product pages, dynamic shipping option/cost calculations based on the user's address (if logged in) or IP address (if not logged in), determining applicable coupons, cross-sell, up-sell, CTAs, dynamically based on the user's history and profile data, etc... You make a lot of db calls. Even caching stuff on the app tier you have to load that stuff in from the db at least once, etc... Again this is all dependent on your application and needs, but saying you should rewrite it to move more logic into the DB isn't really useful in many scenarios.

If you need things like dynamic cloud scaling, read only slave replication, etc... chances are you're doing a lot of DB transactions as well, and that latency can and will kill you.

jaylevitt3• 15 years ago

I wonder if they have any "special sauce" in running PostgreSQL on EC2, or if the real value is in the easy provisioning? We're running PG 9.0 on EC2 now via EBS, and everything I've read says it's tough to get it performant - even with large volumes and RAID 10, you still get spikes when your virtualization neighbors slam the disk.

notaddicted• 15 years ago

Considering their "Continuous Protection" feature, could they be streaming a write log out to S3? I think that way they could use the backup as the sole guarantee of durability, and use instance storage for the database.

EDIT: also, I'm not sure if this is generally known elsewhere, but might they not be on ec2, they are advertising 1.7 GB cache, which is the same as a small instance, except without any room for the operating system or postgres itself.

imbriaco• 15 years ago

You're exactly right about log streaming to S3. We open sourced the tool that we use to perform that: https://github.com/heroku/wal-e

mark_l_watson2• 15 years ago

Someone at Heroku wrote a very useful article a few years ago on getting around the pain points of EBS, using RAID on EBS, etc. (This is probably the article I remembered:http://orion.heroku.com/past/2009/7/29/io_performance_on_ebs...)

moe• 15 years ago

I/O performance is still abysmal even on their largest instance type when striping over 20 EBS volumes (I benchmarked that a while back). And we still noticed a high variance in I/O performance during peak hours despite the striping.

Any recent dedicated server with 16 spindles will completely annihilate EBS in terms of IOPS. And that's with plain old spinning rust - add some SSDs and EBS ain't even in the same ballpark anymore.

joevandyk3• 15 years ago

I wouldn't use EBS. Instance storage is much more consistent, in terms of latency and performance.

jaylevitt3• 15 years ago

I didn't realize that; in fact, I thought I saw something that claimed the opposite. It'd be great to see someone write up a HOWTO for WAL-E and PG9 replication on ephemeral stores in EC2.

mark_l_watson2• 15 years ago

I wish that they also sold their minimal shared 20GB $15/month database plan as a separate service (i.e., being able to access it from your own EC2 instances and not just from Heroku deployed apps).

I have a use case for a low volume app that I would like to host on Heroku, but have other software also have access to the database, without resorting to the obvious workarounds.

sjs382• 15 years ago

I think this is amazing, and immediately had a project in mind for this. But then, I looked at their pricing: $200/mo at the lowest price point.

It's still incredibly affordable, but not for what I had in mind. I wish they had lower levels so I could play.

Anjin• 15 years ago

I'm guessing that they will shortly as it seems like it is a big market hole to plug. I'd bet that since the lowest priced dedicated DB for a heroku app is $200, they've just moved that functionality over.

There's probably some complexity in getting shared cheaper DBs available that we don't know about.

jtchang• 15 years ago

I don't know about you guys but one of the cheapest optimizations you can do is making sure your database and application server are "close" to each other.

Does a cloud database service make sense? Maybe. Databases have gotten easier and easier to setup. In addition they are quite optimized in terms of processing power. I'm not sure I want to give up control my database just yet.

KaiX• 15 years ago

why is PostgreSQL instead of MySQL? What are the advantages of Postgres over MySQL in DBaaS implementation?

I've seen some Database-as-a-service projects and all of them chooses PostgreSQL.

mgkimsal• 15 years ago

licensing might be an issue.

einhverfr5• 15 years ago

Probably because for the sorts of applications dbaas implementations target, PostgreSQL dominates the market among open source solutions.

MySQL is very popular on the web site, but as a database serving multiple applications from the same db, PostgreSQL has been the de facto choice in the open source world since I have been working with db's (at least the last 12 years).

tlogan• 15 years ago

Hmm.. It seems expensive. For this price I would chose Oracle Database RDS. Small Oracle DB instance is ~120/month on AWS.

CarlHoerberg• 15 years ago

Disclaimer: I own Cloud Postgres

Soon to be released: https://www.cloudpostgres.com/

Lower prices

PostgreSQL 9.1

Optional PGPool in front of the replicas for load balancing

Multiple datacenters

Heroku Postgres: SQL Database-as-a-Service

Related Stories