SQL vs NoSQL — which database should you pick?

What each category actually is

• SQL / relational (Postgres, MySQL, SQL Server, Oracle) — Data lives in tables with strict schemas. Rows have relationships (foreign keys). Queries use SQL. Strong consistency and transactions across multiple tables. The default answer for structured business data since the 1980s and still the right default in 2026.
• Document (MongoDB, Firestore, DynamoDB) — Data lives as JSON-like documents. Schema is flexible per document. Best for hierarchical data where you always access the whole document at once. Good for fast-changing product schemas early in a product's life.
• Key-value (Redis, DynamoDB, Memcached) — Simple key → value lookups. Extremely fast, no query language. Perfect for caches, session stores, rate limiters, and leaderboards. Terrible for anything that needs querying by anything other than the key.
• Wide-column (Cassandra, ScyllaDB, DynamoDB) — Row-based like SQL but denormalized and optimized for very high write throughput at massive scale. Only relevant when you have Twitter-scale write load. If you're not sure, you don't need it.
• Graph (Neo4j, Neptune) — Data lives as nodes and edges. Fast for traversal queries (friends-of-friends, shortest path). Overkill for typical business data; genuinely useful for social graphs, recommendations, fraud rings.
• Search (Elasticsearch, OpenSearch, Meilisearch) — Purpose-built for full-text search and analytics. You store data here in addition to your primary DB, not instead of it.
• Vector (pgvector, Pinecone, Weaviate, Qdrant) — Stores embeddings for similarity search — the retrieval layer for RAG and semantic search. In 2026, pgvector on top of Postgres covers 80% of use cases; dedicated vector DBs win at massive scale.

Why we recommend Postgres as the default in 2026

Postgres in 2026 is a hybrid database wearing a relational hat. It handles: transactional workloads with strong consistency, JSONB documents with indexing (rivals MongoDB for many use cases), full-text search (rivals Elasticsearch for small-to-medium scale), time-series data (with TimescaleDB extension), geospatial (PostGIS), and vector similarity search (pgvector). One database, one query language, one operational surface, one backup strategy. The productivity gain from not running multiple databases is enormous, especially for teams under 30 engineers.

When NoSQL is actually the right pick

The pattern that works: use Postgres as the primary store, and add a specialty database only when a specific access pattern demands it. Never adopt NoSQL as a philosophy — adopt it because you hit a specific limit.

• Redis: caching and ephemeral data — Session stores, rate limits, pub/sub, leaderboards, real-time counters. Postgres can do all of these but Redis does them 10–100x faster with less memory. Almost every real product ends up with Redis alongside Postgres.
• MongoDB or DynamoDB: genuinely schema-less product data — If your product schema legitimately changes weekly and each document has a wildly different shape (early-stage CMS, form builders, integrations layers), document DBs pay off. If your schema is stable, Postgres JSONB does the same thing.
• Elasticsearch or Meilisearch: large-scale search — Postgres full-text search is great through a few million records. Beyond that, dedicated search infrastructure with tokenization, ranking, and typo tolerance is worth the second system.
• ClickHouse or DuckDB: analytics on huge datasets — OLAP workloads (analytics, aggregations, dashboards) over hundreds of millions of rows. Column-oriented storage beats Postgres by 10–100x for these queries. Snowflake and BigQuery are the managed equivalents.
• DynamoDB: massive-scale key access with predictable latency — Amazon's serverless key-value store. Great when you know your access patterns in advance and need single-digit-millisecond reads at any scale. Terrible if you need to run ad-hoc queries.

The traps in each direction

• MongoDB for relational data — Storing tightly-related business data (customers, orders, invoices) in MongoDB usually leads to reimplementing joins in application code. The engineering time you spend doing that erases any schema-flexibility win.
• Postgres at massive scale without care — Postgres can absolutely handle billions of rows, but requires real DBA discipline — partitioning, vacuum tuning, connection pooling, read replicas. Teams that expected 'just use Postgres' to be operationally free hit walls at 100–500GB.
• Running five databases because each one was 'best for the job' — Every additional database is an ops burden — backups, monitoring, upgrades, on-call knowledge, security. A single-database team ships faster than a polyglot team until real scale forces the split. Delay the split as long as possible.
• Choosing DynamoDB for a product with unclear access patterns — DynamoDB is amazing when you know your access patterns; painful when you don't. Most early products don't yet know their access patterns. Postgres is more forgiving.