Write down how the data will be used
Before naming any product, describe the queries. What gets read, how often, by what key, and in what shape. What gets written, at what rate, and whether writes must be immediately visible to other readers.
Most database arguments are conducted without this information, which is why they tend to be settled by preference rather than by fit.
Decide what consistency you genuinely need
Some data must be correct the instant it is read — balances, stock levels, permissions. Some can be a few seconds stale with no consequence — activity feeds, view counts, recommendations.
Eventual consistency is a legitimate trade for scale, and a serious mistake where a stale read causes a wrong decision. Classify each dataset explicitly rather than applying one model everywhere.
Default to relational
A mature relational database handles a very wide range of workloads, enforces integrity for you, supports arbitrary queries you have not thought of yet, and has decades of operational knowledge behind it.
It is also increasingly capable outside its traditional territory — JSON documents, full-text search, geospatial, and queuing all work adequately at moderate scale. Choose something else when you can name the specific property it lacks.
Know what the alternatives buy
Each specialised store solves a particular problem well and costs you generality.
- Document stores — flexible schema, at the cost of integrity you now enforce in application code
- Key-value — very fast simple lookups, no querying by anything but the key
- Wide-column — enormous write throughput, with the access pattern fixed at design time
- Graph — relationship traversal that is genuinely awkward in SQL
- Search engines — ranked text retrieval, not a system of record
- Time series — efficient storage and rollup of ordered measurements
Count the operational cost of each store
Every additional database is another thing to back up, monitor, upgrade, secure, and debug at three in the morning. Two stores is more than twice the work of one, because knowledge is split.
Adding a specialised store is justified when a specific workload genuinely does not fit, not because it suits one part of the data model marginally better.
Plan for being wrong
Access patterns change and scale arrives unevenly. Keep database access behind a layer thin enough that the store can be replaced, and avoid spreading vendor-specific features through application code unless they are the reason you chose it.
Ask early how data comes out. A store you cannot export from is a decision you cannot revisit.