Introduction to AWS Data Stores: Relational, Key-Value, Document, and Analytics

When you build an application, you need to store data somewhere. But not all data is the same. Think about the difference between a bank transaction, a shopping cart session, a product catalogue entry, and a yearly sales report. Each of these has a different structure, different access patterns, and different performance needs. AWS provides multiple types of data stores to handle these variations efficiently. Let's break down the four main categories you'll encounter in the DEA-C01 exam.

A relational data store is one that organises data into tables with rows and columns, where each row represents a record and each column represents an attribute. The key feature is that you can define relationships between tables using keys. For example, a 'Customers' table might have a CustomerID column, and an 'Orders' table might reference that CustomerID to link orders to customers. AWS's main relational data store is Amazon RDS (Relational Database Service), which supports familiar databases like MySQL, PostgreSQL, and Microsoft SQL Server. Relational stores use a language called SQL (Structured Query Language) to query data. They are ideal for applications that need strict consistency, complex joins, and transactions — like banking systems, e-commerce platforms, and customer relationship management (CRM) software. The downside is that they can be slower when scaling to massive workloads because they enforce a rigid schema and relationships.

A key-value data store is the simplest type of NoSQL database. It stores data as a collection of key-value pairs. The key is a unique identifier (like a customer session ID), and the value is the data associated with that key (like a shopping cart). AWS's main key-value store is Amazon DynamoDB. You retrieve data by specifying the key, which makes reads and writes extremely fast and predictable. Key-value stores are designed for high throughput and low latency, making them perfect for caching, session management, real-time bidding, and gaming leaderboards. They do not support complex queries or joins; you get exactly one item per key. They also scale horizontally easily — meaning you can add more servers to handle more traffic without slowing down.

A document data store is another type of NoSQL database that stores data as documents, typically in JSON or similar format. Unlike key-value stores where the value is opaque, document stores let you query on the document's internal structure. Each document is self-contained, meaning it holds all its own data — for example, a product document might include the product name, price, description, and reviews all in one JSON object. AWS's main document store is Amazon DocumentDB (compatible with MongoDB). Document stores are ideal for content management systems, user profiles, product catalogues, and mobile app backends where data is semi-structured and evolves over time. They offer more flexibility than relational databases because you can have different fields in different documents, but they don't enforce a fixed schema.

An analytics data store is designed not for transactions but for analysing large volumes of historical data. These stores are optimised for complex queries that scan millions of rows to produce summaries, trends, and reports. AWS's main analytics data store is Amazon Redshift, a data warehouse that uses columnar storage (storing data by column rather than row) to speed up analytical queries. Other analytics services include Amazon Athena (serverless querying of data in Amazon S3) and Amazon EMR (for big data processing with frameworks like Apache Spark). Analytics stores are distinct from transactional databases because they prioritise read performance for aggregations over write performance for individual records. For example, a retail company might load all its daily sales transactions into Redshift each night, then run queries to find the best-selling products by region.

To summarise, each data store type solves a different problem. Relational stores are for structured data with relationships and strict consistency. Key-value stores are for simple, high-speed lookups by a unique key. Document stores are for flexible, semi-structured data that needs to be queried on content. Analytics stores are for deep analysis of large datasets. The DEA-C01 exam expects you to match these data store types to specific business requirements based on data characteristics (structure, volume, velocity) and access patterns (read-heavy, write-heavy, complex queries, low latency).

AWS also offers specialised variants within each category. For example, Amazon Aurora is a relational database that is MySQL and PostgreSQL compatible but offers higher performance and availability. Amazon RDS supports multi-AZ (availability zone) deployments for high availability. DynamoDB offers DynamoDB Accelerator (DAX) for microsecond latency. DocumentDB has storage auto-scaling. Redshift offers features like concurrency scaling and automatic tuning. As a data engineer, you need to understand these options to design cost-effective and performant data solutions.

Let's walk through a realistic scenario: you work for a growing e-commerce company called 'ShopFast'. The company sells products online and needs to build a new feature that allows customers to view their order history, add items to a shopping cart, and get product recommendations. You need to choose the right AWS data stores for each part of the system.

First, consider the product catalogue. Products have a name, description, price, category, images, and reviews. Each product may have different attributes (for example, clothing has size and colour, while electronics have specifications). A document data store like Amazon DocumentDB would be perfect here because each product can be stored as a single JSON document with its own unique fields. You can query products by category or price range. The flexibility means you can add new product types without changing the database schema.

Second, the shopping cart. Each customer's cart needs to be retrieved instantly when they log in. The access pattern is simple: given a customer ID, get the cart contents. No complex queries are needed. A key-value store like Amazon DynamoDB is ideal. You would store the customer ID as the key and the cart contents (a list of product IDs and quantities) as the value. DynamoDB provides single-digit millisecond latency, so the shopping cart loads instantly. Plus, DynamoDB scales automatically if millions of customers are shopping at once.

Third, the order history. This involves structured data: each order has a customer ID, order date, total amount, status, and a list of items. You need to run queries like 'show all orders for customer X in the last 30 days' and 'total revenue for this month'. For relational data, you would use Amazon RDS with a PostgreSQL or MySQL database. You'd create tables for Customers, Orders, and Order_Items with foreign keys linking them. This ensures data integrity — for example, an order can't exist without a customer. SQL queries allow you to join these tables to produce reports.

Fourth, business analytics. The sales team wants to analyse purchasing patterns across millions of orders to decide which products to promote. You would load the order data into Amazon Redshift, an analytics data store. Redshift can run complex queries across massive datasets, like 'top 10 products by revenue in Q4 broken down by region'. It uses columnar storage so that aggregations are fast. You might set up a nightly ETL (extract, transform, load) pipeline to move data from RDS to Redshift using AWS Glue or Amazon Athena.

Finally, as an IT professional, you would also consider factors like cost, latency requirements, and data consistency. For shopping carts, you might accept eventual consistency (where data might be slightly stale for a short time) because speed matters more than perfect accuracy. For financial transactions in order history, you need strong consistency (every read sees the latest write). You'd document your architecture so that others understand why each data store was chosen. You'd also monitor the system using Amazon CloudWatch and set up auto-scaling for DynamoDB and Redshift to handle traffic spikes.

This scenario shows that a real-world application rarely uses just one data store. As a data engineer, you orchestrate multiple data stores to handle different parts of the application, ensuring each piece fits the data characteristics and access patterns perfectly.