The SQL-versus-NoSQL debate isn't about which is objectively better — it's about which failure modes you'd rather deal with. Here's how to actually decide for your project.
Most teams pick their database before they understand their data, usually because a tutorial used MongoDB or a past project used Postgres. That's a reasonable starting bias, but it's not a decision — and getting this one wrong is expensive to reverse once a few hundred thousand records and a dozen features are built on top of it. The actual decision has less to do with which database is "modern" and more to do with how your data is shaped, how it changes, and what kind of consistency guarantees your application actually needs. (Our comparisons hub has more of these architecture trade-offs laid out the same way.)
What the terms mean today
"SQL" refers to relational databases — Postgres, MySQL, SQL Server — where data lives in tables with fixed columns, relationships are defined with foreign keys, and the query language (SQL) is standardized across vendors. "NoSQL" is a catch-all for everything that isn't that: document stores (MongoDB), key-value stores (Redis, DynamoDB), wide-column stores (Cassandra), and graph databases (Neo4j). These four categories solve genuinely different problems, so "NoSQL" as a single decision is already an oversimplification — the real choice is usually "relational, or a specific non-relational shape that matches my data."
The framing that's actually useful: relational databases optimize for data with fixed, well-understood relationships and strong consistency guarantees. Non-relational databases optimize for flexibility of shape, horizontal scale, or a specific access pattern (fetching one document by ID, or one key-value pair) at the cost of some of the guarantees relational databases give you for free.
Where relational databases win
Relationships are the core of your data model. If your application is fundamentally about entities that reference each other — customers who place orders containing line items referencing products, users who belong to organizations with role-based permissions, students enrolled in courses with grades — a relational database expresses that naturally with foreign keys and joins, and it enforces it: a foreign key constraint makes it structurally impossible to have an order line item pointing at a product that doesn't exist. Reconstructing that same integrity guarantee in a document database means either denormalizing (accepting that data can drift out of sync) or writing application-level checks that the database itself won't enforce for you.
Multi-row transactions matter. If your application needs "debit this account and credit that account, and both must succeed or neither does," relational databases have supported multi-table ACID transactions for decades. Most document databases have added multi-document transaction support in recent years, but it's typically a heavier operation there than in a system built around it from the start, and it's easy for a team to reach for it inconsistently across a codebase.
Ad hoc querying and reporting. SQL is expressive: joining five tables, grouping, filtering, and aggregating in a single query is routine. As soon as a business asks for "revenue by region by month excluding refunds," that request is a normal SQL query, while the equivalent in most document databases means either an aggregation pipeline that's meaningfully harder to write and maintain, or exporting to a separate analytics tool.
Schema enforcement catches bugs early. A relational schema rejects a row missing a required field or with the wrong data type at write time. That's a constraint some teams find restrictive, but the alternative — application bugs that write malformed documents which are only discovered later, at read time, scattered across the codebase — is usually worse in practice than the friction of a migration.
Where non-relational databases win
The data genuinely doesn't have a fixed shape. Product catalogs where different categories have entirely different attribute sets (a book has an author and ISBN; a laptop has a processor and RAM; a shirt has a size and color), user-generated content with arbitrary custom fields, or event logs where the schema evolves weekly — these fit a document model more naturally than a relational one, where every optional field either becomes a nullable column or forces a separate attributes table.
Read/write patterns are simple and access is by key. A session store, a shopping cart, a cache of precomputed data, a leaderboard — these are typically "fetch this one thing by its ID" operations with no need for joins or ad hoc queries. Key-value stores like Redis or DynamoDB are built for exactly this and outperform a relational database on this specific pattern, often by a wide margin, because there's no query planning overhead at all.
Horizontal write scale is a first-order requirement. Systems like Cassandra and DynamoDB were built to write across many machines with no single point of coordination, which matters for genuinely enormous, geographically distributed write volume — think global-scale telemetry or messaging systems. This is a real and legitimate reason to choose non-relational, but it's also the most over-cited one: the vast majority of web applications, including ones with substantial traffic, never approach the write volume where a single well-tuned Postgres instance becomes the bottleneck. Reaching for Cassandra-style horizontal scale before you need it usually just adds operational complexity without a corresponding benefit.
Deeply nested, document-shaped data that's always read and written as a whole. A CMS page with nested content blocks, a form builder's field configuration, a chat message with a variable-length list of reactions and attachments — data that's naturally a single JSON blob and rarely needs to be queried by its internal structure fits a document store's native shape without the join overhead of normalizing it across several relational tables.
The middle ground most teams actually land on
The framing of "pick one" undersells how these tools are actually used in production. Postgres has supported a native JSONB column type for years — indexed, queryable, and constraint-friendly — which means a relational database can hold genuinely flexible, document-shaped data inside specific columns while keeping strict relational integrity everywhere else. This covers a large share of the cases teams reach for MongoDB for, without giving up joins, transactions, or a single system to operate.
The other common pattern is using both, deliberately: a relational database as the system of record for core business data, with Redis in front of it for session storage, rate limiting, or caching hot queries. This isn't indecision — it's matching each data shape to the tool built for it.
Questions worth answering before deciding
- Does the data have real relationships that need enforcing, or is it mostly independent records fetched by ID?
- Do you need multi-table transactions, or is "eventually consistent" genuinely acceptable for this data?
- Will the business regularly ask for ad hoc reports and analytics against this data?
- Is the schema stable, or does it change shape by record (different product types, different form fields)?
- What's the actual expected write volume, in real numbers — not "we might go viral," but a realistic 12-month projection?
- Who's maintaining this system after launch, and which query language and operational model are they already fluent in?
That last question matters more than it gets credit for. A relational database run by a team fluent in SQL, with migrations, backups, and monitoring already understood, will outperform a "more scalable" NoSQL system that the team is learning for the first time in production. Operational familiarity is a real factor in total cost, not a secondary concern.
Beyond the two main categories: specialized databases
The SQL-vs-NoSQL framing tends to flatten a wider landscape into a binary, and two specialized categories are worth knowing even if they rarely become the primary database for a whole application:
Graph databases (Neo4j, Amazon Neptune) store data as nodes and relationships rather than tables or documents, and they excel at queries that are naturally about connections — "friends of friends," recommendation paths, fraud-ring detection, org-chart-style hierarchies. A relational database can answer these questions with recursive joins, but the query gets messier and slower as the relationship depth grows; a graph database is built to traverse arbitrary-depth relationships efficiently. This is a genuinely narrow use case for most business applications, but it's the right tool when the core value of the product actually is the relationships themselves.
Time-series databases (InfluxDB, TimescaleDB — the latter built as a Postgres extension) are optimized for data that's overwhelmingly append-only and queried by time range: sensor readings, application metrics, financial tick data. They handle the specific access pattern of "insert constantly, query by time window, aggregate over time buckets" far more efficiently than a general-purpose relational table would at high volume, through storage layouts built around that exact pattern.
Vector databases (Pinecone, Weaviate, or Postgres's pgvector extension) have become relevant to a much wider range of projects recently, because they're what powers similarity search behind AI features — semantic search, recommendation engines, and retrieval-augmented generation all depend on quickly finding the "nearest" vectors to a query in high-dimensional space, which neither a standard relational index nor a document store's indexing is built to do efficiently. For a team already running Postgres, adding pgvector to handle this need is usually simpler than standing up an entirely separate vector database, unless the scale of vector search genuinely warrants a dedicated system.
None of these are a replacement for the core relational-versus-document decision most projects actually face — they're additions reached for when a specific feature's access pattern doesn't fit the primary database at all, layered alongside it rather than instead of it.
What we default to and why
For the large majority of web applications we build — e-commerce platforms, internal tools, SaaS products, marketplaces — we default to Postgres. It handles relational data correctly, its JSONB support covers the flexible-schema cases that used to be MongoDB's main selling point, its full-text search is good enough to skip a separate search service for small-to-medium catalogs, and the operational tooling around it (managed hosting, backups, monitoring, extensions) is mature. We reach for a non-relational addition — usually Redis for caching and session state — when a specific access pattern calls for it, not as a wholesale replacement for the relational core.
The mistake to avoid isn't picking the "wrong" database in the abstract — it's picking one based on what's trending rather than what your data actually looks like, and discovering the mismatch after a year of feature development has been built against it. That's a expensive migration to make later; it's a cheap conversation to have now.
The cost of switching later is the real reason to get this right early
The most expensive version of this decision isn't picking the theoretically less-optimal database — it's picking one, building a year of features against its specific query patterns and data access assumptions, and then discovering the mismatch once the application is large enough that migrating means rewriting a substantial share of the data layer while the business keeps running on the old one throughout. A relational schema with poorly chosen tables can usually be repaired with a migration and some downtime; moving an application's core data model from a document store to a relational one (or the reverse) after significant feature development is a project on the scale of a partial rebuild, not a quick swap. This asymmetry — cheap to get right at the start, expensive to fix later — is the practical argument for spending real time on this decision before writing the first feature, rather than treating it as a detail to revisit once the "real" work begins.
