When would you choose a document database like MongoDB over a relational database?
Quick Answer
Reach for a document database when your data's shape varies significantly between records, when you naturally read/write "the whole object" together rather than joining many normalized pieces, when the schema needs to evolve quickly without coordinated migrations, or when you need to scale writes horizontally more easily than a traditional single-primary relational setup allows. Avoid it when you need strong multi-record transactional guarantees across many related entities, or when your data is genuinely relational (many-to-many, deeply normalized) and would just be fighting the document model.
Detailed Answer
Good fit signals
Variable, nested, or evolving schema per record. A product catalog where a "shoe" and a "laptop" have almost entirely different sets of attributes maps naturally onto flexible documents; forcing it into a fixed relational schema means either a very wide table full of mostly-NULL columns, or an entity-attribute-value pattern that's awkward to query.
{ "type": "shoe", "size": 10, "width": "medium", "color": "black" }
{ "type": "laptop", "ram_gb": 16, "screen_inches": 14, "cpu": "M3" }
Read/write "the whole object" as a unit. If your application almost always fetches an entire user profile (with nested preferences, addresses, recent activity) in one shot, storing it as one document avoids the join cost of assembling it from several normalized tables every time.
Rapid schema iteration without coordinated migrations. Adding a new optional field to a document requires no schema migration — new documents can simply include it, older documents without it are handled with a default in application code. A relational schema change (ALTER TABLE ADD COLUMN) is usually safe too in modern engines, but document stores make this iteration even more frictionless for genuinely unstructured/varying data.
Horizontal write scaling. Document databases like MongoDB are built with sharding as a first-class, well-supported feature from the ground up, often making it more straightforward to scale write throughput horizontally than retrofitting sharding onto a relational deployment.
Poor fit signals — stick with relational
Deeply relational data with many meaningful many-to-many relationships. If your domain genuinely has complex, normalized relationships that need to be queried from many different angles (not just "fetch this one entity and its nested children"), you'll end up either duplicating data across many documents (with the sync/consistency problems that brings) or re-implementing joins in application code — usually a worse position than just using a relational database with proper foreign keys.
Strong consistency across multiple related entities. If a business operation must atomically update several distinct entities together with strict guarantees (a financial transaction touching multiple accounts), a relational database's mature multi-table transaction support is the safer, more battle-tested default — even though modern MongoDB does support multi-document ACID transactions, it's a comparatively newer feature.
Complex ad-hoc reporting/analytics across the full dataset. SQL's join and aggregation capabilities, plus the surrounding tooling ecosystem (BI tools, reporting frameworks), are generally more mature for cross-cutting analytical queries than most document databases' query languages.
The realistic answer
Most production systems benefit from evaluating this per data domain, not system-wide — a core "orders and accounts" domain often stays relational for consistency and reporting, while a "product catalog" or "user activity feed" domain might genuinely be better served by a document store, coexisting in the same overall architecture (polyglot persistence).