The boring answer is usually right
Database selection attracts far more debate than it deserves for typical business software. Orders, customers, invoices, users, permissions — that is relational data with relationships and consistency requirements, which is exactly what relational databases are for.
Choosing something exotic for a conventional problem imports operational complexity, a smaller hiring pool and unfamiliar failure modes, in exchange for benefits you probably will not use.
Why relational still wins for business data
- Transactions that either fully happen or fully do not — essential wherever money is involved
- Constraints that prevent invalid data at the database level, not just in application code
- Joins, which is what business questions are made of
- Decades of tooling, documentation and people who know it
- Modern versions handle JSON perfectly well when you genuinely need flexible fields
The three situations that justify something else
- Genuine document-shaped data with wildly varying structure and few cross-record relationships. Rare in business applications, common in content and event capture.
- Time series at real volume — sensor readings, metrics, market ticks. Purpose-built stores are dramatically better here.
- Search as a core feature. Full-text search across large corpora is a specialist job; use a search engine alongside your relational database rather than instead of it.
Notice that all three are additions rather than replacements. The common mature architecture is a relational database as the system of record, with a specialist store alongside it for one specific job.
Managed or self-hosted
Managed. For almost every business application, a managed service is the right call: backups, patching, failover and monitoring handled by people who do it constantly.
Self-hosting makes sense when you have specific residency or compliance constraints, an existing operations capability, or scale where the cost difference is genuinely material. For a business without a dedicated infrastructure team, self-hosting a database is a liability wearing a cost saving.
Decisions that matter more than the engine
- Schema design. A well-designed schema on an average database beats a poor one on a fashionable database, every time.
- Indexing. The single largest performance factor in practice, and the most commonly neglected.
- Backups you have actually restored. An untested backup is a hope.
- Migration discipline, so schema changes are versioned, reviewable and reversible.
- Connection management, which is where surprising production problems tend to come from.
Plan for the boring failures
The realistic risks are not exotic. Someone deletes data by accident. A migration locks a table during business hours. A query nobody noticed becomes slow as a table grows. Storage fills up.
Point-in-time recovery, migrations tested against production-sized data, slow query logging with alerts, and disk monitoring cover almost all of it, and none of them depend on which engine you chose.