Great Stack to Doesn't Work Bonus: SQL vs NoSQL: Which One in 2026?

The honest decision framework, not another flame war.

The SQL vs NoSQL debate has been running for 15 years and it still generates more heat than light. Here's the framework that actually helps you decide.

The Real Question

It's not "SQL or NoSQL." It's: what does your access pattern look like?

If your application is mostly reading and writing related data through well-defined queries — orders with line items, users with addresses, products with categories — relational databases are purpose-built for this. JOINs are not expensive when they're indexed. Transactions are not slow when they're scoped correctly. PostgreSQL handles 50 million rows comfortably on a single node.

If your application is reading and writing self-contained documents with predictable access by a primary key, and you rarely need cross-document queries — user profiles, product catalogs, content management — a document database simplifies your code. No ORM mapping hell. No migration files for adding a field.

If your application writes massive volumes and reads by partition key with eventual consistency — time-series data, IoT telemetry, activity feeds at scale — wide-column stores like Cassandra were built for this specific workload.

The 2026 Reality

PostgreSQL has eaten NoSQL's lunch in many areas. JSONB support means you can store and query unstructured data inside PostgreSQL with GIN indexes. You get the document model flexibility without giving up transactions, JOINs, and a 30-year ecosystem. For 80% of startups and mid-size companies, PostgreSQL is the only database you need.

MongoDB has gotten more relational. Multi-document ACID transactions (since 4.0), schema validation, aggregation pipelines that look suspiciously like SQL. It's converging toward what PostgreSQL already does, but with a different starting point.

DynamoDB dominates serverless. If you're in AWS and your access pattern is simple key-value with known query patterns, DynamoDB's pricing model (pay-per-request) and operational simplicity are hard to beat. But the moment you need ad-hoc queries or flexible access patterns, you're fighting the database.

Cassandra is for a specific scale problem. If you don't need to write millions of rows per second across multiple data centers with tunable consistency, you don't need Cassandra. The operational overhead is significant.

Decision Tree

Start with PostgreSQL unless you have a specific reason not to. Then:

• Need flexible schema with primarily key-based access? → Consider MongoDB


• Need massive write throughput with geographic distribution? → Consider Cassandra


• Need serverless, pay-per-request, AWS-native? → Consider DynamoDB


• Need time-series at scale? → Consider TimescaleDB (PostgreSQL extension) or InfluxDB


• Need graph queries (social networks, recommendation engines)? → Consider Neo4j or PostgreSQL's recursive CTEs

The worst decision is choosing NoSQL because "we might need to scale." Scale is not a database choice. It's an architecture problem. Most applications will never outgrow a single well-configured PostgreSQL instance. And the ones that do will need to re-architect regardless of their database.

The One Thing Nobody Tells You

The database you choose determines your debugging story. When something goes wrong with PostgreSQL, you have EXPLAIN ANALYZE, pg_stat_statements, 30 years of Stack Overflow answers, and a query planner that tells you exactly what it's doing.

When something goes wrong with Cassandra, you're reading GC logs and compaction stats. When DynamoDB throttles your reads, the only fix is to provision more capacity or redesign your partition key. When MongoDB's aggregation pipeline is slow, the explain output is a nested JSON document that takes 20 minutes to parse.

Choose the database whose failure mode you're most equipped to handle. Because it will fail, and your ability to debug it determines your recovery time.

Over to You

SQL or NoSQL for your current project — and why? Has anyone actually migrated from one to the other mid-project? How did it go?

If you enjoyed this, I write about production engineering, AI systems, and the messy reality of building software at scale.

Follow me:

This is part of the **Great Stack to Doesn't Work* series — a survival guide for when everything goes wrong in production. Follow the series to catch every episode.*