Start from the default
Business applications have related entities, need consistency, and get queried in ways nobody predicted. That is the exact profile relational databases handle, and departing from the default should require a specific reason.
The reasons to depart are narrow
Genuinely schemaless documents, extreme write volume, time-series at scale, or graph traversal as the primary access pattern. Each is real and none applies to a typical business system, however appealing the alternative sounds.
Choosing an exotic database for a normal application means you now have two problems and one of them recurs at 3am.
Operations matter more than features
Who runs it, how it is backed up, how you restore it, and who can debug it at 3am. That last question is the same one that decides your stack, and it outweighs most feature comparisons.
Managed unless you have a reason
Self-hosting a database means owning patching, backups, failover and tuning permanently. Unless you have someone whose job that is, managed hosting is cheaper than it looks once an untested backup becomes a real restore.
Design the schema for the questions
The engine matters less than whether your data model answers what the business will ask. Getting that wrong is what forces a genuine rewrite; getting it right survives several engine changes.
Adding a second store is a real decision
A cache, a search index, or an analytics copy each add a system that can be out of sync with the primary. Sometimes necessary — always a new class of bug, and one that surfaces as data that disagrees with itself.