Decision: SQL or NoSQL (which database family)?
Choosing the right database family is determined by the shape of the data model, your consistency and scale priorities, and your query complexity. Generalizations such as 'NoSQL is more modern' are misleading; each family is designed for specific access patterns. Starting from the structure of the data, this tree guides you to the right tool among relational, document, key-value, and search engines, and reminds you of the polyglot approach when needed.
What is the nature of the data and the dominant access pattern?
Start with the most decisive question: is the data structured records with strong relationships, documents with a flexible/variable schema, simple key-value lookups, or a special need such as text search? The shape of the data and how you query it largely determine the family.
- Relational, structured records and complex queries
- Nested documents with a flexible/variable schema
- Simple key-value, very low latency/caching
- Full-text / faceted search, log analytics
Is strong consistency (ACID) or horizontal scale the priority?
The data looks relational; but what is your priority? Are multi-table joins, transactional integrity, and strong consistency (ACID) essential, or is it horizontally scaling a huge volume that will not fit on a single node? The relational model is the right default for most workloads; it is strained only when scale truly exceeds a single node.
- ACID, joins, and complex query integrity come first
- Scale above all else, weak relationships/joins
Recommendation: Relational database (RDBMS)
The right default for workloads with structured, strongly related data that require transactional integrity. ACID guarantees, a mature SQL query engine, and joins let it answer complex questions reliably.
Recommendation: Document database
Stores flexible, nested data with a frequently changing schema in its natural form (JSON-like documents). Suitable for applications that mostly read/write through a single document, need few joins, and need horizontal scale.
Recommendation: Key-value store / cache
Designed for workloads that need very fast reads/writes by key and no complex queries. It usually runs in memory and provides microsecond/millisecond latency; ideal for tasks such as caching, sessions, and counters.
Recommendation: Search / analytics engine
An inverted-index-based engine specialized for full-text search, relevance ranking, faceted filtering, and high-volume log/text analytics. It delivers the search experience that relational LIKE queries cannot.