The difference between Database and Storage services, and when to use each
Database for structure, Storage for whatever
A common cause of confusion when working with cloud infrastructure comes when trying to differentiate storage and database. Both are useful and extremely valuable, however if we want to build efficient, cost-optimized and well-architected frameworks we need to be sure to use the appropriate solution depending on the use case.
The main difference between storage and database is that Database solutions are more structured in how they store data. You have standard SQL solutions like mySQL, Postgres etc. as well as NoSQL solutions like DynamoDB. Keep in mind that even though there are NoSQL solutions in the database tier, they are still structured in a way that uses key value pairs as opposed to standard table formatting.
With storage, particularly S3 as it is the most commonly utilized AWS storage service, you can throw just about anything in there in the form of objects and/or files. Storage can also potentially provide you with higher throughput and performance if we think about something like Elastic Block Storage (EBS), which is designed to work hand in hand with the most commonly used compute service, EC2.
Now that we know database is for more structured data, we can think about deploying a framework that utilizes both database and storage simultaneously. Lets look at an example to tie them together.
Lets assume the example above is for your social media site, where your ALB is an application load balancer that handles user login requests. These requests are routed between 2 app servers located in a private subnet. The storage attached to those EC2 instances acting as web app servers helps process both incoming requests and responses with content from the back end databases. If there are a large number of requests coming in you may want to consider a higher performing EBS store to attach to those instances for faster processing. If it is a small value and there is no real data you need to store you could consider an instance store volume instead of an EBS block as it would be cheaper. Remember though that once an instance is terminated data on the instance store volume is gone forever. On the other hand if you write data to S3 (as log files for example) and store it as objects there it is extremely durable and can be kept for as long as you want.
Once a login is successfully authenticated and allowed the database layer comes into play by getting the appropriate values for this user that logged in. For our example if we are using RDS we could say that the values we are getting back are name, birthday, likes, friends, hobbies, etc. Various values that would populate someone’s social media page. Then the database sends that back to your web app servers, which take the response and render it on the page to the end user.
Although this is a simple example, hopefully it helps you to think more about how database and storage solutions serve different purposes but can work together very well.
Also remember that the pricing for storage and database are different as well. However in general, with storage solutions what usually costs money is the amount of objects stored and how often/where you transfer it. Database costs are generally associated with your database instance sizes and how much you are storing. More information can be found about the costs associated with S3 and EBS (storage) here and here, and RDS and DynamoDB (database) here and here.
Hopefully this was helpful, and as always good luck with your continued journey in cloud computing.
