TopolearnPicking a store for the wrong reasons is expensive; the right choice follows from access patterns and guarantees needed.
"NoSQL" covers several different models, each optimised for something specific:
- Relational (PostgreSQL, MySQL): flexible queries and joins, constraints, transactions. The best default when you don't know all future queries, and modern versions handle JSON well.
- Document (MongoDB): self-contained JSON-like documents; great when data is read and written as a whole aggregate (an order with its lines). Cross-document relationships and transactions are weaker or costlier.
- Key-value (Redis, DynamoDB at heart): get/put by key at very low latency; caches, sessions, counters. You must know the key.
- Wide-column (Cassandra): massive write throughput across many nodes, tables designed per query, tunable consistency.
- Graph (Neo4j): traversals over many-hop relationships.
- Search (Elasticsearch, OpenSearch) and analytical/columnar stores for full-text and OLAP.
Questions that decide it:
- Do you know the access patterns up front? NoSQL stores usually want you to design tables per query; relational lets you query new ways later.
- Do you need multi-row transactions and constraints?
- Does the data fit one machine (with replicas)? Most applications do, for a long time.
- What does the team already operate well?
A common, sensible architecture is a relational database as the system of record, plus specialised stores (cache, search index, warehouse) fed from it. Choose NoSQL for a concrete need — scale, latency, a data shape — not because the schema feels inconvenient.
Remember
- Relational is the best default when queries will evolve
- NoSQL stores are optimised for specific shapes and access patterns
- System of record in SQL plus specialised stores is a common, strong design
Watch out for
- Picking a schemaless store to avoid designing a schema, then reinventing constraints in code.