The database you pick shapes every feature you build after it. Model the data first, then choose the store — not the other way round.
SQL databases (PostgreSQL, MySQL) store data in tables with a schema and speak in joins and transactions. NoSQL is a family of models — document stores like MongoDB, key-value stores like Redis, wide-column stores like Cassandra — each of which trades some of the relational model’s guarantees for a specific kind of scale or flexibility. The wrong way to choose is by fashion; the right way is by the shape of your data and the queries you’ll actually run.
If your data is entities with relationships — users, orders, products, invoices — the relational model fits it natively. Joins answer questions you didn’t anticipate when you designed the schema, transactions keep multi-row changes consistent, and constraints stop bad data at the door. PostgreSQL in particular has become the safe default: JSONB columns for flexible documents, full-text search, and extensions like PostGIS and pgvector mean it covers many “NoSQL” use cases too.
Modern managed Postgres (RDS, Cloud SQL, Neon, Supabase) also removed most of the old scaling anxiety: read replicas, connection pooling, and vertical headroom carry the overwhelming majority of products further than they’ll ever grow. Choosing NoSQL “for scale” before you’ve saturated a well-indexed Postgres instance is optimizing for a problem you don’t have.
Document stores fit data that is naturally a self-contained blob — a product catalog entry with wildly varying attributes, a CMS page tree — read and written as a unit, where schema flexibility matters more than cross-entity queries. Key-value stores like Redis are unbeatable for caching, sessions, queues, and counters. Wide-column stores like Cassandra and DynamoDB shine when write volume is enormous and access patterns are known in advance and key-based.
The common thread: NoSQL asks you to know your query patterns up front and denormalize for them. That’s a fair trade at scale, and a painful one while the product is still discovering what questions it needs to ask of its data. It’s also why most real systems end up polyglot — Postgres as the system of record, Redis for speed, and a specialized store only where the workload demands it.
Your data is relational — entities that reference each other and get queried in ways you can't fully predict.
Consistency matters: payments, inventory, bookings, anything where a partial write is a bug.
You want one store that can also handle documents (JSONB), search, and vectors while you grow.
A workload is key-based at high volume — sessions, caching, real-time counters.
Documents are self-contained and schema varies per record by design.
Write throughput or global distribution genuinely exceeds what a relational primary can absorb.
Not as a blanket statement. Each is faster at the access patterns it's designed for — Mongo at whole-document reads and writes, Postgres at relational queries and aggregates. Benchmarks that ignore your actual query shapes are marketing.
For many products, yes — JSONB columns give you schema-flexible documents inside a relational database, with indexing. You lose some document-store ergonomics at the extreme, but you keep transactions and joins.
PostgreSQL, almost always — plus Redis for caching when performance demands it. Add a specialized store only when a measured workload outgrows that pair. It's the choice that keeps the most doors open.
Yes, and most real systems do — Postgres as the system of record, with a NoSQL store like Redis or a document database handling the specific workload it's best suited for.
Not entirely — many NoSQL databases offer tunable consistency, but the strong, ACID-style guarantees relational databases provide by default usually require deliberate trade-offs to replicate in NoSQL.
A practical comparison of data warehouses, data lakes, and lakehouses — where each one fits, what they cost, and how to pick the right one.
Read the guideOwnership, quality checks, access control, and a lightweight catalog — governance that makes data trustworthy without a bureaucracy.
Read the guide