Choosing AWS RDS Database?

[P00HB33R]

Hi Guys,

Hope someone can assist me and shed some light on this. I am in the process of designing a SaaS. I won't go into details for obvious reasons, but I need to try and figure out what AWS Database Instance will best suite my needs.

The usage will be as follows:
1. <=500 users a month
2. <=200 Transactions per user per day
3. Most transactions will read/write/update/delete either a single record, or a set of records (Not more than 20 records per call)
4. About 20% off transactions will be Single row + related child records CRUD
4. Multi Tenant Schema
5. DB Size will be +- 20GB At most

I am currently using the AWS RDS for MariaDB t3 micro which is 2OCPU + 1GB MEMORY. Its fine for my development purposes, but I need to calculate my monthly costs, and the Database is by far the most expensive component.

Any comments, help or insight would be very much appreciated.

 

[Sinbad]

Rather than rds, have you thought about dynamodb?

 

[P00HB33R]

Rather than rds, have you thought about dynamodb?

Hi, what would be the be benefit be using dynamodb over mariadb?
And what would be the cost implication?

 

[Sinbad]

Hi, what would be the be benefit be using dynamodb over mariadb?
And what would be the cost implication?

You don't need to worry about actually running the dB.

Plug your expected volumes into the aws cost calculator to see it it works for you?

 

[Harmonic]

Since you're just starting up, why not use some docker containers on an EC2 instance to keep it simple. You can change and scale up as your user base grows and you start to validate your business model/find product market fit

 

[P00HB33R]

Since you're just starting up, why not use some docker containers on an EC2 instance to keep it simple. You can change and scale up as your user base grows and you start to validate your business model/find product market fit

Thanks for this. I already have the clients. Its a matter of completing the app, and launching. Thats why I need to figure out what size to start with.

 

[P00HB33R]

You don't need to worry about actually running the dB.

Plug your expected volumes into the aws cost calculator to see it it works for you?

AWS RDS also manage the database for you. Would I be able to create relationships in DynamoDB eg. foreign key constrainst etc as I can in mysql/maria/sql?

Had a quick look, and it seems to me that you are billed per table? Am I correct in that assumption? My app has quite a lot of tables, so the cost would be prohibitively high

 

[B-1]

You can always use something like locust to see the impact of your expected worse case and tune it to your needs.

Even though you gave us quite a bit of info we don't know how complex the queries are or how much tuning and indexing etc you did. Testing is the only thing that will give you a real idea of what is going to happen.

 

[P00HB33R]

Hi, what would be the be benefit be using dynamodb over mariadb?
And what would be the cost implication?

So I had a better look, and it seems I had it wrong. Multiple entities can be created in a single table. So this is a viable solution. Thank you

 

[neoprema]

So i was going to post something very similar.

I have a need to write about 250/s "inserts" to a DB. I setup Dynamo and I have approx 100 EC2's running processing something and shoving it into Dynamo.

Here's what i learnt the last 4 days:

1. DynamoDB does NOT allow delete * or anything similar so if you want to delete all your test data in a table you have to drop it and recreate it. It does support some basic sql queries but for the most part I have to interact with it in Python with Boto3. That said its not difficult, but remember its a noSQL DB, not an RDS.

2. The default setup will not give you enough write units per second, which you'll only find out the hard way when you run your stuff and wonder why half the info is missing only to find out the dynamob db client (boto3) was spitting out errors on the console that you've exceeded your Throughput. DynamoDB works with read and write "units". 1 Write unit means you can write up to 1KB at one time. So if you have 250 trying to write at one time, your options are: implement delays/back-offs (there are some built-in to boto3 but they don't work at large scale) or 2. Increase your writes. Again cost will go up but its not insane and once configured correctly - DynamoDB is VERY VERY FAST.

3. Get your DynamoDB hash value (for table partitioning) right and it works even better. Read up on it on AWS docs.

 

[P00HB33R]

So i was going to post something very similar.

I have a need to write about 250/s "inserts" to a DB. I setup Dynamo and I have approx 100 EC2's running processing something and shoving it into Dynamo.

Here's what i learnt the last 4 days:

1. DynamoDB does NOT allow delete * or anything similar so if you want to delete all your test data in a table you have to drop it and recreate it. It does support some basic sql queries but for the most part I have to interact with it in Python with Boto3. That said its not difficult, but remember its a noSQL DB, not an RDS.

2. The default setup will not give you enough write units per second, which you'll only find out the hard way when you run your stuff and wonder why half the info is missing only to find out the dynamob db client (boto3) was spitting out errors on the console that you've exceeded your Throughput. DynamoDB works with read and write "units". 1 Write unit means you can write up to 1KB at one time. So if you have 250 trying to write at one time, your options are: implement delays/back-offs (there are some built-in to boto3 but they don't work at large scale) or 2. Increase your writes. Again cost will go up but its not insane and once configured correctly - DynamoDB is VERY VERY FAST.

3. Get your DynamoDB hash value (for table partitioning) right and it works even better. Read up on it on AWS docs.

Thank you very much for this. I think i will delve a bit deeper into DynamoDB.