I've used SQL and NoSQL solutions, such as MongoDB and MySQL. I would not choose Dynamo to be a primary datastore and one of the others is likely a better option. Dynamo is good as almost viewed as a large cache. If you want something that is more supported and easier to work …
As a fully managed NoSQL service, DynamoDB provides a lot of functionality for relatively low cost. Scaling, sharding, throughput performance is managed for you, and you only pay for the bandwidth you provision.
While evaluating Cassandra, PostgreSQL, MongoDB and DynamoDB we found Cassandra and DynamoDB being well suited for us. At the same time we didn't have the luxury of large team or devops so it came down to Amazon DynamoDB. As a small team we are glad to go forward with this …
I've been using MySQL for so long that it's my go-to RDBMS. I really like MySQL Workbench in conjunction with MySQL. I've experimented with Amazon DynamoDB in my personal time.
MySQL stands in better place when it comes to cost. It is also an inexpensive database. We selected this database due to the cost as first reason. Secondly we do not have complex database manipulation requirements separately. Occasionally we need to generate reports which we do …
Well suited: DynamoDB is ideal for web and mobile applications that experience rapid and unpredictable traffic spikes. Its ability to auto-scale in response to demand ensures consistent performance under heavy loads. DynamoDB is well-suited for managing user sessions and user profiles in applications, ensuring quick access to session data without compromising performance. Less appropriate: DynamoDB is optimized for storing structured data but may not be the best choice for storing large binary files like images, videos, or documents. In such cases, using a dedicated storage service like Amazon S3 is more appropriate. If your application has consistent and predictable workloads that do not require frequent scaling, the cost-effectiveness of DynamoDB's on-demand pricing model may be less appealing compared to provisioned capacity.
From my own perspective and the tasks that I perform on a daily basis, MySQL is perfect. It has a reasonable footprint, is fast enough and offers the security and flexibility I need. Everyone has their preferred applications and, no doubt, for larger data warehouses or more intensive applications, MySQL may have its limits, but for the area that I operate in, it's a great match.
Security: is embedded at each level in MySQL. Authentication mechanisms are in place for configuring user access and even service account access to applications. MySQL is secure enough under the hood to store your sensitive information. Also, additional plugins are available that sit on top of MySQL for even tighter security.
Widely adopted: MySQL is used across the industry and is trusted the most. Therefore, if you face any problems, simply Google it and you shall land in plenty of forums. This is a great relief as when you are in a need of help, you can find it right in your browser.
Lightweight application: MySQL is not a heavy application. However, the data you store in the database can get heavy with time, but as in the configuration and MySql application files, those are not very heavy and can easily be installed on legacy systems as well.
Although you can add the data you require as more and more data is added, the fixity of it becomes more critical.
As the demand, size, and use of the system increase, you may also need to change or acquire more equipment on your servers, although this is an internal inconvenience for the company.
It's core to our business, we couldn't survive without it. We use it to drive everything from FTP logins to processing stories and delivering them to clients. It's reliable and easy to query from all of our pipeline services. Integration with things like AWS Lambda makes it easy to trigger events and run code whenever something changes in the database.
For teaching Databases and SQL, I would definitely continue to use MySQL. It provides a good, solid foundation to learn about databases. Also to learn about the SQL language and how it works with the creation, insertion, deletion, updating, and manipulation of data, tables, and databases. This SQL language is a foundation and can be used to learn many other database related concepts.
Functionally, DynamoDB has the features needed to use it. The interface is not as easy to use, which impacts its usability. Being familiar with AWS in general is helpful in understanding the interface, however it would be better if the interface more closely aligned with traditional tools for managing datastores.
I give MySQL a 9/10 overall because I really like it but I feel like there are a lot of tech people who would hate it if I gave it a 10/10. I've never had any problems with it or reached any of its limitations but I know a few people who have so I can't give it a 10/10 based on those complaints.
For us, it performs well in most of the regions. It surely provides a seamless experience as it has greatly helped in us providing real-time analysis on huge datasets which has greatly reduced time to customer which was not the case before. It is responsive at all scales for sure.
The support staff is friendly, knowledgeable, and efficient. I only had to get part way through my explanations before they had a solution. They will walk you through a fix or actually connect in and fix the problem for you--or would if you can allow it. I've done it both ways with them. They are always forthcoming with 'how to do this if it happens again' information. I love working with MySQL support.
Comparing RDS and Dynamo is not fully Apples to Apples comparison. RDS is a more flexible cloud-native solution that supports a wide range of engines that are relational. It is great for running older DB types like Oracle in the Cloud. Because it supports multiple engines, it is a popular choice for doing hybrid design between Cloud and On-Prem. DynamoDB is a Key Value database option, which shares some of the performance and security that RDS does with a more specific focus/use case.
MongoDB has a dynamic schema for how data is stored in 'documents' whereas MySQL is more structured with tables, columns, and rows. MongoDB was built for high availability whereas MySQL can be a challenge when it comes to replication of the data and making everything redundant in the event of a DR or outage.
DynamoDB is very easy to scale. It is easy to log into the UI console and create tables according to scalability needs. My personal experience with DynamoDB has been excellent since I had little to no experience, but the documentation and industry support are excellent, and any developer can readily pick it up to use for developmental purposes.
Some developers see DynamoDB and try to fit problems to it, instead of picking the best solution for a given problem. This is true of any newer tool that people are trying to adopt.
It has allowed us to add more scalability to some of our systems.
As with any new technology there was a ramp up/rework phase as we learned best practices.
