What is our primary use case?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
I have been using Amazon RDS since 2017. My company has a partnership with Amazon.
What do I think about the stability of the solution?
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.
What do I think about the scalability of the solution?
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.
How are customer service and support?
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.
How was the initial setup?
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.
What was our ROI?
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.
What's my experience with pricing, setup cost, and licensing?
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.
What other advice do I have?
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.