SQL vs NoSQL: How to Choose a Database

This choice is made once and lived with for years, usually by whoever is in the room on day three. The good news is that for the overwhelming majority of business applications the correct answer is well established.

Why relational is the sensible default

• Your data is almost certainly relational — customers have orders, orders have items. Modelling that as documents means duplicating and re-syncing it yourself.
• Transactions across multiple records, with real guarantees, without application-level coordination.
• Ad-hoc querying: the business will ask a question nobody anticipated, and SQL can answer it without a migration.
• Constraints and foreign keys catch data corruption at the boundary rather than six months later.
• Modern PostgreSQL and MySQL handle JSON columns well, so schema flexibility is no longer an argument against them.

When a document store earns its place

• Genuinely variable structure per record — product catalogues with wildly different attributes, or ingested third-party payloads.
• Read patterns that always fetch one self-contained aggregate by id.
• Rapid early iteration where the schema changes daily and the data is disposable.

When a specialised store is the right call

• Key-value (Redis, DynamoDB) — caching, sessions, counters, and very high-throughput lookups by key.
• Wide-column (Cassandra, Bigtable) — enormous write volumes across many nodes, with known query patterns fixed in advance.
• Time series — metrics and sensor data, where a purpose-built engine outperforms everything else by a wide margin.
• Search (Elasticsearch, OpenSearch) — full-text relevance ranking, alongside your primary database rather than instead of it.
• Graph — when traversing relationships many levels deep is the core query, not an occasional report.

Questions that settle the argument

• What are the ten queries this application will run most? Design for those, not for a category.
• Do you need multi-record transactional guarantees? If yes, relational makes life much easier.
• What's the realistic data volume in three years — not the optimistic one?
• Who will operate this at 3am, and do they know how?

Polyglot persistence, carefully

Using two databases for two genuinely different jobs — relational for transactions, search for relevance — is normal and good. Using five because each was individually interesting is how teams acquire an operational burden they can't staff. Every additional datastore is another backup, upgrade, and failure mode to own.