Choosing Storage

Start with operations, not a database name

At this point we have several storage models, each strong for a particular workload profile. To choose a store, it helps to follow the same path every time: describe the data, access patterns, required guarantees, and scale, and only then compare options.

Match the problem to the model

• Relational Database — when relationships, constraints, transactions, and flexible queries over structured data matter.
• Key-Value Store — when the main access path uses a known key and a simple fast read or write is needed.
• Document Database — when data naturally lives as aggregates with nested and evolving structure.
• Column-Oriented Database — when large analytical scans and aggregations over a subset of columns dominate.
• Object Storage — when large binary objects need to be stored cheaply and reliably.

This is not a strict truth table. Concrete products overlap in their capabilities, so the final decision must be validated against real workload and operational requirements.

Check the important worst case

The average request rarely determines architecture. It is more useful to ask what happens during peak write traffic, when a table grows tenfold, when a node fails, or when data must be restored after a mistake.

If a solution works only in normal conditions but does not meet requirements during failure, that is part of architectural risk rather than a “rare case.”

Count operational cost

An additional database means separate backups, monitoring, upgrades, access controls, team expertise, and recovery procedures. Sometimes a less specialized but already familiar store is the better choice for the current scale.

Different data can require different solutions

If one model truly cannot cover different workload profiles, the system can be split by responsibility. For example, transactional data can remain in a relational database, files can move to object storage, and fast lookup data can use a key-value system.

orders  -> relational database
sessions -> key-value store
media    -> object storage

The key is for every dataset to have a clear source of truth and clear synchronization rules between stores.