| Factors |
Comments |
| Read-heavy or write-heavy or balanced? How many reads/writes per second for the current user base? How does this change when the user base increases? |
- RDBMS can read scale with replicas. Write scale limited to single instance capacity. For write, options such as sharding available.
|
| Concurrency – How many concurrent users your system would have? How does it grow over next few years? |
- Concurrent reads and writes matters in this decision making. NoSql databases supports high concurrent writes.
|
| What’s the latency requirements? |
- Prefer NoSql variants for low latency requirements.
|
| Data storage – What’s going to be the storage size? How does it grow? |
|
| Frequency of data access – How often the stored data are accessed? |
- For backups, use archival systems.
|
| Nature of data – What data you wanna persist? Relational express in tables? Documents? Binaries? Mixed? |
- If it’s binaries, consider data stores.
- Consider NoSql variants such as (K,V), document, graph, etc.
|
| Data integrity needs – Is this the source of truth? |
- If complex transactions is not the need, consider NoSql databases.
|
| Tolerance to stale data |
- Look at the read replicas and sync/async updates for RDBMS. Focus on consistency models to scale out.
|
| Queries – Are queries are relational? Possible to de-normalize? |
- For de-normalized data, consider NoSql databases.
- For reporting and BI applications, consider dataware house.
|
| In-house skillset – Which technology your developers are comfortable with? What’s the learning curve with new technology? |
|
| Knowledge on the data – Possible to setup schema in advance? Schema free? |
- For flexible data models, choose NoSql databases
|
