Storage Requirements

Describe the data workload first

Before choosing a database, you need to understand what the system will store and how that data will be used. The same data volume can require completely different solutions if one system mostly reads while another constantly writes and updates.

A useful start is to ask a few questions: how much data appears, which operations dominate, what latency the user expects, and what happens if part of the data is temporarily unavailable or lags behind.

Volume and growth

You need to estimate not only the data size today, but also how quickly it is produced. If a system creates 50 GB per day, that becomes tens of terabytes over a year even before replicas, indexes, and backups.

daily growth = 50 GB
one year    ≈ 18 TB

Retention time matters for some data. Raw events may be kept for a few months, while a user profile may live for years. The retention policy directly affects the final volume.

Reads and writes

The system should understand not only total RPS, but also the operation mix. For example, a product catalog may have many reads and relatively few changes, while device telemetry may generate an enormous number of sequential writes.

The access shape also matters: lookup by identifier, time range, several fields, a complex join, or a large analytical scan. The access pattern often determines the appropriate storage model.

Latency, availability, and consistency

Some operations can tolerate responses in hundreds of milliseconds, while others need the fastest possible access. Some data can temporarily be read with a small update delay, while for other data the user must immediately see the result of their write.

Availability requirements should be defined separately: can the operation wait for recovery, or must the service continue responding when part of the infrastructure fails?

Data has a shape too

Data structure influences the choice just as much as workload. If entities are strongly related and integrity rules matter, that is one problem profile. If an object is usually read as a whole and has a flexible set of fields, that is another.

Only after such a description does it make sense to compare concrete storage classes. Without it, selection becomes an argument about technologies without a connection to the problem.