Hacker News Reader

Comment by andrewgodwin | Hacker News Reader

Sad to see the recommendation to use MySQL - in my experience RDS hasn't been worth the effort - but I'm probably biased since I already invested the time in automating PostgreSQL replication setup.

View on HN

Believe me, I am sad to stop using Postgres. What parts of RDS haven't been worth the effort? I didn't have to make much effort, beyond rewriting my Postgres triggers into MySQL syntax.

Did you consider using Heroku Postgres?

I'm not the OP, but the thing that's always scared me off from those types of services is that I think there would be high latency, where in a DB you really need low latency. Is that not true?

Since Heroku runs on EC2, as long as OP kept his servers in the same availability zone as the DB, latency shouldn't be any worse than running it himself. But yes, in general I'd be wary of a database far away from my app servers.

That can depend on whether you can hit the internal IPs, or just the external IPs. If you can only hit the external IPs, you're subject to greater network latency, plus data transfer fees.

RDS is pretty expensive for what you get. You can't restore to a running instance from snapshots, you get very little control over the environment, and you can't replicate between geographic regions (only availability zones).

I know you said you're a two man shop, but in this case it may make more sense to leverage other IaaS DB services instead of RDS.

I am not sure what you mean by "You can't restore to a running instance from snapshots" cause, well, I've done it a few times.

Could you expand a bit maybe?

I have also used their snapshots with success

My apologies. I should've said "to an existing instance."

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_R...

"You must create a DB snapshot before you can restore a DB instance from one. When you restore the DB instance, you provide the name of the DB snapshot to restore from, and then provide a name for the new DB instance that is created from the restore. You cannot restore from a DB snapshot to an existing DB instance; a new DB instance is created when you restore."

"you get very little control over the environment" also seems spurious. You get parameter groups to control just about everything you can from a standalone mysql instance. logs or things that load from disk (LOAD DATA ...) are the only things you can't touch, but a small price to pay for automated backups, failover and scaling (both up AND down...)

Sorry if I wasn't specific enough.

In my opinion, you don't get enough control over the environment for what you're paying on a per hour basis. Automated backups? Great, they aren't that difficult to being with. Failover? Sure, within the same AZ, when you need to be doing it between datacenters. Scaling? I will grant that it scales up and down fast automagically.

I've seen RDS have significant per-query overhead, and some very, very variable read times - in particular, some simple SELECTs randomly taking > 10s every so often.

Is your ec2 instance in the exact same zone/region as your rds instance? An ec2 instance in us-east-1a will have extra latency dealing with an instance in any other zone, even us-east-1c.

Stating us-east-1a means nothing, since your us-east-1a is someone else's us-east-1d. They're not the same across AWS accounts.

Right, but 1a is never the same as 1c.

RDS is subject to the exact same intra-region latency issues that other AWS instances have. Perhaps worse in some cases, since their failover appears to be DRBD based.

Inconsistent performance, significantly slower than MySQL on a real box, and failure of the ridiculously expensive automatic failover were the reasons I dumped RDS. I ate a big loss after reserving instances, but seeing the server fall off the planet, and no spare ever take over for it despite paying for MultiAZ, what other response would have been reasonable?

We came across this issue as well, we'd been wasting too much time setting up Postgres. RDS seemed liked a good choice, except that MySQL is just that much worse than Postgres. We had just used things like concurrent indexes.

We ended up going with Heroku's hosted Postgres solution. It costs the exact same we were spending w/ two High CPU instances w/ provisioned IOPS volumes. Now we get fully managed, same price, and all the features of Postgres.

We still host our full application on AWS, the only thing is that we have a managed database. While Postgres makes it easy to setup replication and what not, AWS hardware just sucks. It takes time to properly tune it.

What tier of postgres do you use? How's performance?

In my experience RDS has been amazing, and I am a MySQL guy. I say it like that because as a MySQL guy I would much prefer to setup my own server and use a third party engine like Percona or Maria, but RDS(MySQL) performance has been incredible.

The only thing I would complain about is the lack of a proxy or load balancer in front of their Multi-AZ setup. With any failover you are forced to have a downtime of 3-5 minutes while DNS propagates.

A month or so ago I thought about starting a hosted Postgres service on top of EC2, since lots of people seem to want "RDS for Postgres." I think if you specialized you could beat Heroku's offering, but ultimately I decided there was too much risk of Amazon simply adding Postgres themselves. But if anyone is more daring than me, perhaps there is an opportunity here.

I believe EnterpriseDB already offer something like this: http://www.enterprisedb.com/

I saw this in the AWS marketplace (aws.amazon.com/marketplace) - http://www.enterprisedb.com/cloud-database/amazon

no experience or affiliation, though.

I saw that, but I could do better. :-) Heroku's Postgres-only option is the product to beat. It makes it really easy and has some great replication features. But a dedicated company could offer more.

I hadn't seen it prior reading/replying to your comment, but I thought it looked comparable to RDS as I skimmed http://www.enterprisedb.com/products-services-training/produ...

I've not used Heroku's Postgres stuff, so no idea what it offers beyond that

I wouldn't say there is much effort required at all with RDS. We use it without issue and while there are some annoying issues with limited access to the environment, it's been pretty solid for us.

Reply on news.ycombinator.com