Hacker News Reader

Comment by aidos | Hacker News Reader

In my experience you get much better performance outside of RDS and you can inspect and tune it better. Maybe I’m missing something and no doubt I could put more work into it but we’ve actually talked about moving our RDS dbs back to EC2 because there are plenty of queries we do that are embarrassingly slow on RDS when they shouldn’t be.

Also, you can’t replicate out of RDS. I like to know where my data is and how to bring it back online during a disaster.

View on HN

I've worked on a project that migrated from MySQL on EC2 to MySQL on RDS and then back to EC2 because the performance was massively worse — a process that took a few hours before now took days. We contacted Amazon support to try and resolve whatever was going wrong with the RDS instance, and their response was basically "Yeah, we don't guarantee performance on RDS. If you want to maximize performance, you should run your own DB on EC2."

It makes sense because of the dependency on EBS, but what instance type were you using on RDS? Using provisioned IOPS RDS disk?

We tried a few very large instance types to see if that made any difference, and provisioned IOPS did help, but everything was still slower than the EC2 DB and it cost a lot more on top of that.

RDS is better than running your own but in my experience, RDS was always kind of a meh product. One of my friends was telling me that they don't dogfood RDS internally since relational databases aren't allowed at Amazon.

That's true to a fair degree. If you're running your AWS service using a relational database in AWS, they'll have your guts for garters. However, that's because of the sheer level of scaling that services have to operate at. Consider the number of requests per second that they handle. Scaling gets fiendishly complicated under those circumstances.

That's not to say that it's impossible to do. Facebook ably achieves it. It's just that the level of expertise that would be required across so many services is significant. AWS has hundreds of services, each of which would need to be hiring highly skilled DBAs to handle the sharding etc. etc. etc necessary to scale. It's easier to just point people at DynamoDB where they've effectively handled all those needs for you, you just have to put a bit more logic in your application side, which also has the neat property of scaling horizontally more easily.

You can replicate out of RDS without any problems. Shoot, you can run a master in EC2 and a replica-only in RDS.

I do this presently because I have some custom stuff I do for MySQL which needs it's own EC2 instance because RDS doesn't support it.

My knowledge may be out of date now - is that with Postgres? Hopefully so.

My gripes with the performance issues still stand though. I have queries that take 30-40 seconds on RDS that complete in milliseconds on an EC2 instance which is much smaller.

That's super bizarre. Are you running MySQL with no ACID on EC2 while leaving RDS at its defaults or something?

I seem to recall there was a time in RDS product lifecycle where replication out was not available. It seemed to me (at the time) a mechanism to ensure lock-in. I now think it was just natural product evolution, adding features as they were able to do so, which varied by DB engine.

What do you mean by replicate because my old teammate was able to set up a slave from a RDS master to a non-RDS database.

Postgres RDS or Postgres Aurora?

What’s more likely. That your one data center has a disaster or a globally redundant AWS infrastructure.

Reply on news.ycombinator.com