Amazon RDS Reviews

I use mostly the Postgres incarnation of Amazon RDS. Basically, Amazon RDS is a cheap database that is totally self-contained and self-managed, and that is its good part. There is also the downfall associated with the tool since you don't have you don't have root privileges or super-user privileges on Amazon RDS, so there are certain things you cannot do. Sometimes, when I really needed a database that I could have absolute control over, I used to spin AWS VMs and EC2 machines and load Postgres on that machine so that I could become a super-user. Amazon RDS is very useful for quick and dirty or for very established solutions where you don't have to develop or change a lot. Basically, you can you can load your data into Amazon RDS. In my data analytics space, I see Amazon RDS as an ancillary product to Redshift, which is the real workhorse in terms of big data, data warehousing, and analytics.

I don't manage my database with Amazon RDS. AWS manages Amazon RDS. Sometimes, it is enough, and I don't need to do low-level stuff, and I can use Amazon RDS. Suppose I really need to tweak and do low-level stuff, low-level in the sense of being very close to the system, and I need super-user privileges. In that case, Amazon RDS is out of the picture because AWS doesn't allow you to have super-user privileges in Amazon RDS. The use case for me with Amazon RDS is a cheap and dirty database that I can use when I don't need to do a lot of tweaking. When I need tweaking, I create my own instance of the Postgres, and I can become a super-user and do whatever I like.

As a customer of Amazon RDS, you don't have super-user privileges, and that is the only drawback where improvements are required.

I never tested the scalability of the product. I was scaling it up to two, three, and four gigabytes, and it was fine. I don't know how it fares when we are loading hundreds of gigabytes of terabytes of data. Redshift can manage huge amounts of data, but I don't know about Amazon RDS. I suspect Amazon RDS can handle huge amounts of data because Postgres is very capable of doing so. Amazon RDS in AWS is simply an umbrella. Underneath Amazon RDS, you can choose to implement MySQL or other databases. The implementation I always chose was Postgres.

I have been using Amazon RDS since 2017. My company has a partnership with Amazon.

AWS is a stable environment. Postgres is a very stable database. AWS implementation of Postgres, as far as I know, is very reliable. I never had any issues.

I never tested the scalability of Amazon RDS since it was, for me, a stepping stone toward having real analytics in Redshift. Basically, Amazon RDS was just a collector. I was collecting structured data into Amazon RDS, or if the data was unstructured, like in emails, I was using software to make sense of the email and then store the content of the email relationally in Amazon RDS. Amazon RDS was just a stepping stone, a part of the pipeline, just in order to collect the data momentarily so that the data could eventually be transferred across to Redshift.

The tool's technical support depends on your service level agreements with Amazon. If you are on the cheap side, obviously, they tend not to attend to your issues immediately, and I can understand that. If you pay a premium support fee, I don't know how Amazon treats you since I was never in a position to pay a premium support fee. Overall, I was never disappointed with the tool's support. I didn't face a lot of issues, so I never tested how good the support was because I have 35 years of experience in managing data. I tend to solve my own issues by myself.

The product's initial setup phase is totally easy. You go to a web page, configure your instance with checkboxes and drop-down list boxes, see what you want, see what your needs are, and what you are prepared to pay, compile a form with ten or fifteen fields, click on submit, and Amazon RDS is created for you.

Going from on-premise and hybrid into a complete Amazon RDS solution obviously frees up the need for DBAs. The fact that AWS manages everything for you means you don't need a lot of time and resources to manage the database. So you can cut your yearly salary for the DBAs in your company. You need to consider all the cloud costs as well. I believe it is cheaper to go with Amazon RDS rather than hosting Postgres instances in-house or on-premise. I know that AWS is becoming expensive. I really don't know where the breakeven point is between having your own Postgres instance that you manage yourself outside the cloud. Basically, there are three options. You manage your Postgres on-premise. You use an EC2 VM in AWS, and you install Postgres on it. You have the benefits of AWS scalability and security, but you still have your control, and you become a super-user on the database. The third option is to go with Amazon RDS, after which you lose control of your database, but you don't worry about managing redundancy and creating high-availability solutions because everything is done for you. I believe it is the best feature of RDS, which is total uptime guaranteed by AWS. You don't need to think about how to implement, test, and manage a high availability redundancy kind of solution, as everything is included in the package.

I don't know if the solution is cheap or expensive in comparison with competitors since AWS is the only cloud provider I tried so far. I connected some Azure Blob Storage to the instance running the Redshift instance. AWS is becoming pretty expensive because cheap or absolutely free services have become paid services. Amazon RDS is not an expensive product, but Amazon's ecosystem is becoming increasingly expensive.

In my experience, there is no need to maintain the product. I didn't try the tool's scalability. I was using the TRUNCATE TABLE command in every other ETL. TRUNCATE TABLE means I empty the data every time I load it. It was just a relational storage mechanism, basically, for a few gigabytes of data daily. Each ETL on a daily basis in the pipeline is used to erase what was there for the previous jobs and reload Amazon RDS, and when the loading in Amazon RDS was complete, there was another process in the pipeline that we used to bring the data across to Redshift. I never used it in a very sophisticated manner.

I have not tested the AI capabilities with the product. I know that a lot of the competition, whether inter or intra-cloud, is fierce nowadays, and AI solutions are popping up everywhere. I simply haven't had the chance yet to test the AI capabilities in AWS. It will be my next project.

The trade-off is between control and peace of mind. If you want control, and obviously, you cannot choose RDS. If you want peace of mind and you don't want to think about backing up the database or creating a high availability policy around it, then definitely go for Amazon RDS. If you have some, if you are a startup, for instance, testing new things, I wouldn't go for Amazon RDS simply because you don't have control over the database. If you are an established company and want to move from on-premise to the cloud, you have the once-off migration task from your on-premise into the cloud, and everything has already been concretized. The database that supports the application is already well-established. If you are not introducing new features or experimenting with the product to introduce new features, then Amazon RDS is a good choice.

I rate the tool a seven to eight out of ten.

The benefits I experienced while using Amazon RDS stemmed from the fact that it provided me with the database and helped with managing searches in AWS. With Amazon RDS, you have your database without worrying about infrastructure, updates, or other things.

The shortcomings stem from not Amazon RDS as a product but are related to its monitoring capabilities. I feel Amazon RDS should have a lot of functionalities to make monitoring within the database easier. Amazon RDS should provide more granularity of log entries.

I have had a few years of experience with Amazon RDS. I was a user of the solution.

I found it to be a stable solution.

I never needed the solution's technical support.

Amazon RDS was the first tool with which I used databases or services on the cloud.

Currently, I work with Microsoft Azure SQL Database in my new company.

Speaking about Microsoft Azure SQL Database, you would always have the latest version and latest update since Microsoft is the owner of the Microsoft Stack.

Amazon RDS is easy to deploy and integrate, but it depends on the solution. Maybe if you need to restore your database in a different region or in a different account or want to run Amazon RDS databases in multi-account environments, then it can be really hard and painful.

Amazon RDS is an expensive solution.

I would tell those who plan to use Amazon RDS to understand how it works and determine the pricing part before purchasing it since it is expensive.

The ease of using Amazon RDS depends on your platform, design, and software. Amazon RDS is easy to use if you have an AWS infrastructure.

With Amazon RDS, integrations with third-party solutions can be easy and beneficial for the product's monitoring part only. In general, integrating Amazon RDS with third-party solutions can be a complex process.

I rate the overall product an eight and a half out of ten.

The product is pretty good for small or mid-scale organizations that don't have the luxury of proper DBAs or a large infra team. Scaling up and down is relatively easy without a proper setup. And apart from reducing these overheads, you have better performance insights if you use a server. And if you are serverless, your costs are lower. So we use both.

Concerning performance, when a cluster upgrades from lower to upper config, the connection drops. This could be solved by better coding and settings and included in the next release.

It's supposed to be scalable, but we don't feel that. True, there won't be any drops. The solution they gave was to maintain our cluster at a level sufficient for our peak load. However, that will probably defeat the whole purpose of on-demand scalability. So that is certainly where we might need to rethink the solution. It actually works in real-time, but it's not at a level where we can think of five seconds or 10 seconds there. 

We've been using the solution for three years.

Two of our products are in production on RDS, so we use RDS extensively. RDS routers are valid on two of our product suites. And then RDS SQL Server 2016 instance 52 is on many of our client implementations.

It's supposed to be scalable, but we don't feel that. True, there won't be any drops. The solution they gave was to maintain our cluster at a level sufficient for our peak load. However, that will probably defeat the whole purpose of on-demand scalability. So that is certainly where we might need to rethink.

RDS support is decent enough.

We contact tech support about different issues in general and concerning the services we provide. 

Before deployment, we do our POC in a lower environment, making everything very clear. But whenever we have downtime or hiccups, we investigate. And if needed, we reach out to the tech support team for clarification.

One of the challenges of AWS RDS is that it doesn't support performance insight. So we need to write our own script or use third-party tools.

If Amazon could provide the same support for serverless solutions that it provides for server-based ones, like RDS instance-based SQL Server, that would be a great improvement.

I would rank the setup as eight out of 10, along with the Microsoft SQL Server on RDS. It took 10 to 15 minutes. It was straightforward for me as my field is data and data engineering. But it shouldn't be too difficult for anyone unfamiliar with the technologies because the documentation is pretty clear.

We do everything in-house. So typically, we don't hire consultants unless we land up in a very niche area. We also work closely with AWS teams on different POCs before launch.

We are not currently scaling up our legacy infra, so we are definitely seeing dollars there, typically around 3K. Since it's not calculated, I'm giving the figure off the top of my head. So this will be quite a different figure for different people.

On pricing, I would rate RDS six out of 10 because if you don't know how to optimize and use your tool properly, the cost might hurt you. It would've been great if they had some cost alerts. You can usually manage using CloudWatch, but a simple notification that your costs just went up sharply or you overspent would help. I know there are videos and instructions on AWS. I'm not saying it's not there. But when the technology is new to you, it's hard to know what went wrong. And certainly, if you're not looking at your bill, you will be shocked by the amount.

We had one or two bad instances or hiccups, but now we have everything under control. The licensing is fine for us, but it may be a challenge for new users.

I would rate Amazon RDS eight or nine out of 10.

I recommend RDS because it makes your life super easy. You can focus on your main functionality, your product and on maintaining your infra. It is highly recommended for small and mid-sized organizations.

We have thousands of RDS users in our company. 

The number of users is directly proportional to the number of clients and their user tools. As we grow, so will the number of users.

The only deployment we do is for RDS. In fact, the product itself does the whole stack deployment. You don't need a deployment team for RDS when it's service-based or for the separate deployment of S3. The same person can do RDS on S3. Usually, you would have a cloud ops team of two or three, depending on the number of clients and the complexity and size of the projects.

If you're changing your tech stack and working with new cloud technologies, RDS makes sense. And one of the major costs of legacy technologies is RDBMS licensing, which can be managed and used optimally using RDS.

We have on-prem servers and our database is hosted in the cloud on Amazon RDS. Everything is automated there, like setting up backups and replication. We have around 40 persons using RDS.

Amazon RDS gives us the ability to select as many tools, replicas, regions, and zones as we want.

I've used Amazon RDS for six or seven years.

RDS is stable. A cloud solution is always stable, and RDS servers are solid.

Amazon RDS is highly scalable. It is much simpler to scale up compared to an on-premise solution where you need to buy new hardware and migrate all the data. Ifwe need more capacity, there is a symbol that you can click on to upgrade your hardware. 

If you want one more server in a different region, you can spin it up and everything is done on the cloud. You can just select what you need and go, whether you're going to downgrade or upgrade to system type TX for whatever configuration you want.

Amazon support is good, but we've only communicated with them via email so far. We email support when we have questions, and they've always come up with the proper solution.

Before Amazon, we had MySQL and PostgreSQL, but it's not like we switched We still have on-premise solutions and some things in the cloud. Most of our stuff is still on-prem. It depends on if it's a critical application that is heavily used, so you don't have downtime.

Installation is straightforward. You choose your database for RDS, like MySQL, Oracle, PostgreSQL, MongoDB, etc., and select the distance type. It takes a maximum of five minutes time to select and set up the system. Our servers can be up and running in 10 to 15 minutes, and data migration took about an hour.

We have several in-house teams with separate databases, so they usually take care of it for us. I worked on some databases. We have a different method for RDS. One stacked, so we build our own scripts and publish them in the stack.

Amazon RDS is a little costly, but it also reduces the number of full-time employees needed. We require fewer system admins or DBS because RDS reduces our workload. 

It's pay as you go. Once you are using it, you will get support. You don't need to buy a yearly license to get support. If we deployed our server there, we would get support from them.

I rate Amazon RDS nine out of 10. I recommend it. Cost is the only issue. RDS is one of the best choices if you need scalability and reliability, but you're not worried about the cost.

Some of the features will not be there. For example, some on-premises things we want to set up will not be supported there. There are some challenges there that they are fixing. 

I use the solution to store the data of the applications we run on AWS Lambda.

The solution is scalable and can be configured with AWS Secrets Manager. So our password is secure. Also, due to Amazon RDS Multi-AZ, other nodes are available for us if we face a problem in a particular zone. This functionality makes the solution resilient.

If we do not keep track of our costs, we might face some problems.

I have been using the solution for more than three years.

The solution is quite stable. We haven't seen any issues in the last three years. Since we are using Amazon RDS Multi-AZ, other nodes are available on the machine, even if the solution is down. I rate the stability an eight out of ten.

I rate the scalability a seven out of ten. Multiple teams in our organization are using the solution.

We get a timely response from the support team when we raise issues.

The initial setup is quite easy. If we know the configuration, we can run the system, and our database will be ready in 10 to 15 minutes.

If we use the product wisely, we can optimize the cost. The cost depends on the kind of instance we use.

The solution helps us to provide a serverless database. There are multiple servers available in case someone has a high workload. We must understand whether our application is a read-heavy application or a write-heavy application. Accordingly, we must choose the right instance. Overall, I rate the solution an eight out of ten.

We use Amazon RDS for our Oracle Learning system. About five clients or so use it for that. We also offer a database service using Oracle, Amazon RDS, and Microsoft SQL Server RDS for our rental clients. 

Amazon RDS is good for backups, auto-scanning, and disaster recovery. It's also appropriate for the office server. 

An RDS account cannot be shared when you close it. You need an encryption key to clone the data, but you cannot share it. 

I have used Amazon RDS for more than seven years.

The stability is good.

Scalability is an issue. It doesn't handle large data sets well, so we use a different solution for those. This is a limitation of RDBMs, and data doubles every two years. 

AWS support is decent, but it's not as good as before. Sometimes, we get junior staff who are unable to answer our questions. It also depends on the support team you get. Support based in Europe and Australia is better than US support. For example, European support is quick to deliver the right answer. US support handles routine maintenance issues, and it's mostly junior staff who don't know the product well. 

We use multiple solutions from various vendors. It's better to compare Amazon RDS to AWS Aura and MySQL. You pay more with Aura, and it cannot handle our scheduled databases.

I rate Amazon RDS nine out of 10 for ease of setup.

I rate Amazon RDS eight out of 10 overall. 

We use the solution to migrate products from on-premises to AWS environment.

The solution's most valuable feature is the provisioning of products. We don't have to worry about storage approval or hardware availability using this feature. It is the most accessible feature in RDS.

They should add a feature for manual SQL patching in RDS. Also, the auto-patching features have their limitations. We can't set a particular day or date of the month for auto-maintenance.

We have been using the solution for two years.

I have never come across any issues regarding the solution's stability. The database uptime works fine.

Scalability is one of the solution's best features.

The solution's customer service is excellent.

Positive

The solution's initial setup is straightforward.

The solution's pricing needs improvement. I rate it as a six.

If they have to segregate the databases into different RDS databases, it will cost almost the same or even more than any on-premises migration.

I rate the solution as an eight because it quickly provisions the resources. It covers all the security and governance parameters as well.

It's very useful to save customer's data in a secure manner, we can easily handle all the customer records with encryption mode.

Currently, we are not using RDS as, it has some limitations on DB schema creation, it allows limited tenant DB creations...expecting to release RDS custom RDS very soon

It is stable, scalable, and easy to deploy.

Expecting to have AWS RDS custom.

I have been using this solution for almost four years.

It is stable.

It is scalable. We have more than 12,000 users who are using this solution.

When we depend on the AWS technical team, we need to pay more. For tech support, they are charging about 25% of the actual bill, which is too high for me. If it is fixed to something like $200, I can go for that, but currently, it is too high for me.

Positive

Earlier we used Rackspace, it is very costly and more technical depedancy

It is straightforward. It takes only a couple of minutes.

We did it on our own.

Cost always depends on usage

We evaluated azure, but we faced some issues with wild card domains 

The product is pretty good, but its support is very expensive. 

I would rate it a ten out of ten.