What you get for nothing
Postgres and MySQL, the two workhorse relational databases, hand you several things for nothing. Every later decision to use something else is a decision to give some of it back.
You get a declared shape for your data. The database refuses a row missing a user, or holding a word where a number belongs, at the moment of writing, forever, no matter which service or intern wrote the code.
That feels like bureaucracy right up until you debug a store where 4 percent of the records spell a field one way and the rest spell it another.
You get transactions spanning rows and tables. Move money between two accounts, or take stock off the shelf while creating the order, and the database promises both happen or neither does.
Most of the alternatives only promise that within a single record, which quietly moves those guarantees into your application, where they are enforced by hope and retry loops.
You get joins, and a planner that works out how to run them. That means you do not have to know today which questions you will be asked next year.
When finance wants revenue by region by month, it is a new query, not a new table design and a week of backfilling. Stores that pre-arrange your data for one way of reading it make every other way expensive.
What it costs
Count the costs honestly too. One relational machine tops out in the low thousands of writes a second for typical work. Read copies are easy; spreading writes means sharding, which you build and run yourself. Joins across shards mostly stop working. Changing the shape of a two billion row table is a project, not a command.
Take it as your default anyway, precisely because those limits arrive late. Most products die of something else long before they get near them.
Worked example
Karan builds an invoicing product on MongoDB because setup takes ten minutes. A year in, a customer asks for revenue by client by month, net of refunds. Line items are embedded inside invoice documents, refunds live in a separate collection, and the report becomes a 300-line aggregation pipeline plus application-side stitching that takes 40 seconds on 2 million invoices. Worse, issuing a refund has to update an invoice document and insert a ledger entry, and a crash between the two produced 19 mismatched records last quarter. He migrates the money paths to Postgres over six weeks. The report becomes 15 lines of SQL with two joins, runs in 120 ms, and the refund is a transaction. Mongo stays for the one job it was doing well: holding scraped supplier catalogs whose shape changes weekly.