Why Your Application Doesn't Need a Database for Everything
A look at how choosing the right AWS storage service depends on the type of data, access patterns, and application requirements—not just on personal preference.
Why Your Application Doesn't Need a Database for Everything 🗄️☁️
When building an application, it is easy to think of a database as the place where everything should be stored.
Users, images, logs, events, documents, sessions, configuration, and application data can all end up in the same database.
But cloud architecture encourages us to ask a different question:
What type of storage does this data actually need?
The answer is often not the same for every piece of information.
Not all data is the same
Consider an e-commerce application.
It might have:
1
2
3
4
5
6
7
Users
Products
Orders
Images
Logs
Events
Reports
These different types of data have different characteristics.
For example, an order might require relationships and transactions, while a product image doesn't need to be stored as a database row.
Trying to store everything in the same system can create unnecessary complexity.
Choosing storage based on the data
AWS provides several storage and database services, each designed for different workloads.
A simplified architecture might look like this:
1
2
3
4
5
6
7
8
9
Application
|
+----------------+----------------+
| | |
v v v
PostgreSQL S3 DynamoDB
| | |
Transactions Images Key-Value
Relationships Documents Data
The important point is not to choose a service because it is popular.
The important point is to understand the characteristics of the data.
Relational databases
A relational database is useful when an application needs relationships between entities and strong transactional behavior.
For example:
1
2
3
4
5
Customer
|
+---- Order
|
+---- Product
An application such as an e-commerce platform might need to guarantee that an order is created correctly and that its related information remains consistent.
This is a good scenario for a relational database such as PostgreSQL.
Amazon S3 is different
Now imagine that the application needs to store product images.
An image is not naturally represented as:
1
2
3
4
5
6
ProductImage
-------------
id
name
size
binary_data
inside a relational database.
Instead, the image can be stored as an object in Amazon S3.
The database can simply store information about the object:
1
2
3
4
5
6
Product
----------------
id
name
price
image_url
While S3 stores the actual file.
1
2
3
4
5
6
7
8
PostgreSQL
|
| image reference
v
S3
|
v
product-image.jpg
This separation can make the architecture easier to scale and manage.
What about DynamoDB?
Some workloads don't require complex relationships.
Imagine a system where the application frequently needs to retrieve information using a specific key.
For example:
1
User ID → User Preferences
A key-value or NoSQL database can be a better fit for this access pattern.
Amazon DynamoDB is designed for applications that require fast and predictable access at scale using keys and indexes.
Again, the important question is:
How will the application access the data?
And what about logs?
Logs are another interesting example.
Application logs don't necessarily belong in the transactional database.
A simplified architecture could instead be:
1
2
3
4
5
6
7
Application
|
v
Logs
|
v
CloudWatch
Operational data can then be analyzed independently from the application's transactional data.
This separation prevents the primary database from becoming responsible for every type of information generated by the application.
One application can use multiple storage systems
A modern application might therefore look like this:
1
2
3
4
5
6
7
8
9
10
Application
|
+-------------------+-------------------+
| | |
v v v
PostgreSQL S3 DynamoDB
| | |
Orders Images Preferences
Users Files Sessions
Products
This is sometimes called polyglot persistence: using different storage technologies for different requirements.
It doesn't mean that every application should use five databases.
It means that we should avoid forcing every type of data into a storage system that wasn't designed for it.
The trade-off
Using multiple services also introduces complexity.
Now the application needs to deal with:
- More services
- More permissions
- More monitoring
- More configuration
- More architectural decisions
Therefore, adding another AWS service isn't automatically an improvement.
A simple application might be better with one PostgreSQL database.
A larger system with very different workloads may benefit from specialized storage.
The architecture should follow the requirements.
A useful question
When deciding where to store something, I like to ask four questions:
1. What type of data is it?
Is it structured data, an object, an event, a log, or something else?
2. How will it be accessed?
Will the application perform complex queries or mostly retrieve data using a key?
3. What consistency does it require?
Does the operation need strong transactional guarantees?
4. How will it scale?
Will the amount of data or request volume grow significantly?
These questions can narrow down the appropriate technology.
Final thoughts
Cloud architecture isn't about using as many services as possible.
It's about understanding the problem well enough to choose the right tools.
A database is extremely useful, but it doesn't have to become the storage solution for everything.
Sometimes the best architecture is:
PostgreSQL for relationships.
S3 for objects.
DynamoDB for specific access patterns.
CloudWatch for operational data.
The real skill is not memorizing AWS services.
It's learning why you would choose one over another.
☁️ Good architecture starts with the data, not the technology.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article