Choosing a Database Without Reading Forty Blog Posts

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

1. Genuine document-shaped data with wildly varying structure and few cross-record relationships. Rare in business applications, common in content and event capture.
2. Time series at real volume — sensor readings, metrics, market ticks. Purpose-built stores are dramatically better here.
3. 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

1. Schema design. A well-designed schema on an average database beats a poor one on a fashionable database, every time.
2. Indexing. The single largest performance factor in practice, and the most commonly neglected.
3. Backups you have actually restored. An untested backup is a hope.
4. Migration discipline, so schema changes are versioned, reviewable and reversible.
5. 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.

Frequently asked questions