What AWS RDS Class Should I Have at Launch?

deployment
1

I’m fixing to launch my startup. :slight_smile: It’s hosted on Galaxy, with a Postgres db on AWS RDS. I could launch to crickets or to somewhat-rapid growth. I’m kind of going for a slow launch so as to work out the kinks, but I’ll be emailing a lot of potential users shortly after launch, so there may be some activity.

I need the ability to auto-scale my postgres db to more RDS servers if need be.

During development the db has just been on a db.t2.micro. I’m self-financed so I’m being cautious about spending.

What DB instance class or classes would potentially be suitable for my use case?

Thanks very much in advance to all for any thoughts/info!

2

I’m self-financed so I’m being cautious about spending.

Don’t do auto-scaling then bud, just run the biggest db server you can afford and see how performance is. If it barely touches the sides like 0.5 load or under, use a cheaper one. Autoscaling will just fire up as many servers as they can a bit like if you let facebook or google manage your ad bids, it’s a cash machine for Bezos.

1 Like
3

Thanks very much for this advice!

I found out today that:

  • The AWS RDS m class is for stable, predictable workloads
  • The t class is burstable for for short periods of high usage
  • the x, z, and r classes are memory optimized and the fee is based on the amount of memory used

Is the burstable t class the thing you were cautioning me to avoid, or is that something else?

4

Ignore anything they told you, it’s all marketing.

Essentially anytime you let them think for you = biggest bill possible.
The fact is, when a burst happens, it will most likely happen again and again. It’s called a peak time. Like 7pm or whenever your server heats up. So you just want a server that can handle the load and that’s it. No fancy auto stuff.

For database it’s pretty much pointless because can just put a cache in front, cache can run on same server, you only need this burst auto scaling for streaming sports games where you get a one or two hour traffic and then the event is over. If your app falls in that category, you can use it. Otherwise for a general app, just use a server that can handle it. In my experience this is much cheaper, especially if you just run one server which has db, memcache / redis, and web server - zero latency, all on one box and easy to monitor. When your load is up consistently, add another web server, cheap one, quad core, 4gb ram and add that into nginx as a backend, voila you have manual auto scaling, and you control everything. No surprise bills. Remember if a bot hits it, or it got spammed, on auto scaling, you pay.

1 Like
5

FYI here’s how to do load balancing in nginx - you just add the IP to your backend and can even specify the weight (importance) of that server. Make sure to use a good nameserver on your domain, not the free one that came with godaddy etc - so you can filter ddos and bad browsers at the dns level before it connects to your server so you cannot be charged… best of luck with your launch bro!

    upstream backend {
        server backend1.example.com weight=5;
        server backend2.example.com;
        server 192.0.0.1 backup;
    }
}
1 Like