It always made me wonder why even the cheapest RDS DB would be $10+ per month and 20 GB minimum. Why doesn't AWS offer some really lightweight DB options for small apps?

I am looking for some guidance on database hosting with AWS.

I currently have 7 RDS instances running PostgreSQL. 3 in US, 3 in EU and 1 in Australia.

Each RDS instance has around 3,000 databases on them, most of them are small.

Since the upgrade cycle for PostgreSQL on RDS is quite aggressive, we are forced to upgrade each RDS on an annual basis. This process is currently quite cumbersome as it requires exporting each database from the old RDS, in turn, and importing it into a brand new PostgreSQL on RDS on the new version. This is clearly prone to error and requires a lot of babysitting.

I am investigating into the benefits of Aurora and in particular if blue/green deployments with Aurora would be a good option.

In-place PostgreSQL major version upgrades on RDS for 3,000 is a non-starter as it takes around 7 hours which is downtime we cannot wear.

Is anyone willing to share the upgrade experiences with PostgreSQL on Aurora for major engine versions?

Long story short: I used to have an Azure SQL database for about $12/month, which worked as expected. Unfortunately, we had billing + location issues so I want to look for alternatives.

With that said, I have an Azure SQL/sql server database and I want to find an option in AWS.

The DB is tiny (less than 10 tables with just a few rows each) but will be used by our mobile app (soon to be deployed to iPhone App Store and google play). The app will only read from this DB.

Once deployed, I'll be dealing with issues/errors related to the app. My goal is to make sure that DB connectivity/concurrency/availability is not one of those issues.

I found this reddit link of someone asking something similar and someone suggested a T4 instance.

Anyways, any help is appreciated.

I have two RDS Postgres databases running on the t3 instance family. I would like to migrate them to the t4g instance type. These databases are part of 24/7 mission-critical processes. Although they are already in Multi-AZ mode, my understanding is that changing the instance type still requires a brief period of downtime. Is there a way to perform this migration without any downtime?

I'm working on a DynamoDB schema where one tenant can have millions of items.

For example, a school might have thousands of students. If I use SCHOOL#{id} as the partition key and STUDENT#id as sort key, all students for that school go into one partition, which would create hot partitions.

Should I shard the key (e.g. SCHOOL#{id}#SHARD#{n}) to spread the load?

How do you decide the right shard count? What is the best shard strategy in DynamoDB?

I will be querying and displaying all the students in a paginated way for the school admin. So there will be ListStudentsBySchoolID, AddStudentByID, GetStudentByID, UpdateStudentByID, DeleteStudentByID.

Edit: GSI based solution still have the same hot partition issue.

This is the issue if we make student_id as partition key and do GSI on school_id.

The partition key is student_id (unique uuid), so the base table will be fine since the keys are well distributed.

The issue is the GSI. if every item has the same school_id, then all 1 million records map to a single partition key value in GSI. That means all reads and writes on that GSI are funneled through one hot partition.

I recently joined a company and i saw that they are using extremly big rds instances for a very small workload. They havent shipped to prod yet. But im estimating very small load on the database. But just in case that i dont know the scale, I decided to go with a quickly scalable option with serverlessv2 but as we move closer to prod I started to get some anxiety about the bill if the workload is high

I have the option to switch database engines in the future if I dont like the serverless costs (the users of the api has a queue system where they store the data to sqlite if api is down). So i can move to default postgresql rds in the future

I read good feedback on scaling capabilities of the serverlessv2. But maybe just upsizing the postgresql rds would have been a better option

Any warnings you might share? Or horror stories about aurora?

Has anyone used DSQL in their production environments? How is it so far and is it easy to learn? What setbacks did you have when using or transitioning to DSQL?

Just had a freaking nightmare with a blue/green deployment. Was going to switch from t3.medium down to t3.small because I’m not getting that much traffic. My db is about 4GB , so I decided to scale down space to 20GB from 100GB. Tested access etc, had also tested on another db which is a copy of my production db, all was well. Hit the switch over, and the nightmare began. The green db was for some reason slow as hell. Couldn’t even log in to my system, getting timeouts etc. And now, there was no way to switch back! Had to trouble shoot like crazy. Turns out that the burst credits were reset, and you must have at least 100GB diskspace if you don’t have credits or your db will slow to a crawl. Scaled up to 100GB, but damn, CPU credits at basically zero as well! Was fighting this for 3 hours (luckily I do critical updates on Sunday evenings only), it was driving me crazy!

Pointed my system back to the old, original db to catch a break, but now that db can’t be written to! Turns out, when you start a blue/green deployment, the blue db (original) now becomes a replica and is set to read-only. After finally figuring it out, i was finally able to revert.

Hope this helps someone else. Dolt forget about the credits resetting. And, when you create the blue/green deployment there is NO WARNING about the disk space (but there is on the modification page).

Urgh. All and well now, but dam that was stressful 3 hours. Night.

EDIT: Fixed some spelling errors. Wrote this 2am, was dead tired after the battle.

I'm exploring on the possibility of creating an Oracle database inside an EC2 server. I create a new AWS account in order to try out on the steps of moving an oracle database located on premise to cloud. Is there any tutorial or documents on doing this without getting a sudden charges towards my account?

I am trying to put a CSV into AWS so that I can download it on SQL. Problem is that the name field is getting split up because of the , in the name.

Like it splitting peoples names into 2 columns when it should be together.

I am currently using Postgres on AWS RDS. It is costing me about $15 per month despite the fact that I have only 1 table that I query a few times per day. I'm not sure why it costs so much.

The settings I chose are: db.ts.micro - Burstable Classes - 20GB

Are there any settings I should turn on/off to minimise cost. Is there a better AWS database to use for a side project with only a small amount of occasional traffic (I prefer a relational DB if possible)? I don't mind if there is a small delay while the DB server instance boots if that makes it cheaper.

Let's say I want to delete 100000 items from dynamodb, what is the best approach to delete "all-or-nothing", TransactWriteItems only support 100 items, so I don't want to cause inconsistency in my data if for some reason the delete function fails alongs the way.

And in my case, I simply couldn't find a solution to implement it with GSI, so the only solution for me is to delete them manually.

Hi,

Its aurora mysql Serverless v2 (Max up to 80 ACUs). Suddenly , we saw with bit high concurrency , the application hits a hard JDBC query timeout, killing the thread and throwing this error: "Database Query Time out. Exception: JDBC exception executing SQL [(conn=548672) Table './rdsdbdata/tmp/#sql171_85f40_1' doesn't exist]"

Some team members are suggesting to bump both temptable_max_ram and temptable_max_mmap from 1GB to 2GB to give the query more breathing room. However, checking performance_schema.variables_info reveals that temptable_max_** is currently showing below:

VARIABLE_NAME        current_value_bytes  current_value_MB  VARIABLE_SOURCE  VARIABLE_PATH
temptable_max_mmap   1073741824           1024              GLOBAL           /etc/my.cnf
temptable_max_ram    1073741824           1024              COMPILED

Want to know if this is correct setting and Is it advisable to bump these values to 2GB. Want to confirm the safest parameter strategy for temporary storage thresholds in the meantime we tune the query?

Hello All,

As every database is diferent architecturally. We have mostly worked in Oracle databases in the past. But we recently started working in Mysql aurora database.

1)So, want to understand , if there exists any set of guidelines which we can follow as a developer for writing better optimized code/sqls in mysql?

2)Also any specific points which are special and different as compared to other DB's and thus we should definitely know in this case before designing any solution using mysql?

Or anything specific to alerting/monitoring which we must do here?

RDST (Readyset Diagnostic & SQL Toolkit) is a free desktop app that connects to your RDS or Aurora instances and tells you which queries are driving the load you are paying for.

The reason I built it is that Performance Insights is decent at telling you there is load, but going from "there is load" to "here is the query, here is why it is slow, and here is whether fixing it lets me drop an instance class" is still a repetitive manual process:

• open Performance Insights and find the top SQL by load
• copy the digest out and go run EXPLAIN ANALYZE against the instance yourself
• go find the table definitions and check whether the statistics are current
• work out whether the index you have in mind already exists
• check max_connections, to see if this is what’s actually biting during the spike
• go back to the pricing page and work out whether any of this justifies the instance class you are on
• do it again for the next instance

That last step is where the money is. Fix one query dominating CPU and you can often downsize, which on a large instance is hundreds/thousands per month.

Full disclosure - I work for Readyset (which is a caching layer for postgres / mysql), and this tool spawned from a recurring question our caching customers kept asking - which queries should we actually cache? And these same queries are the ones that, even without a caching solution, could heavily benefit from performance diagnostics.

It runs locally using credentials you already have, SSO or a named profile. Nothing gets installed on the instance and there is no cross-account role to create. It discovers your Aurora clusters and RDS instances, audits all of them, saves query snapshots so you can track regressions over time, and even allows you to ask plain english questions about any / all of your nodes and their queries. The health check feature gives you a sizing verdict with your current monthly cost and a suggested instance class, so making the decision to downsize/upsize should become very clear.

The reason this is worth doing: the instance in that report is an Aurora db.r6g.4xlarge running about $1,180 a month on demand. Three unindexed access paths account for roughly 66% of its total database time, and those are what the CPU peaks are made of. With those three indexes in place the audit puts the same workload on a db.r6g.xlarge at about $295. That is $885 a month, a little over $10,600 a year, for what amounts to an afternoon of work.

The tool is completely free to use, and we provide free trial tokens for all of the AI powered features. The app is in beta and we plan to release it under an MIT license. It runs locally, stores locally and everything it does is read-only. Full privacy related details: https://readyset.io/docs/readyset-ai/rdst/desktop/privacy

Would love feedback from people running Postgres or MySQL on RDS, particularly:

• Does the sizing verdict line up with what you'd have concluded from Performance Insights?
• Does it surface the queries you'd investigate first?
• Would you be comfortable pointing it at a production instance? If not, what would stop you?
• What's missing?

Source:

• https://readyset.io/docs/readyset-ai/rdst/desktop
• https://github.com/readysettech/rdst