JSON DB vs. Relational Tables - The battle is over

The default database stopped describing the workload

Teams once asked which relational database would hold the application. A modern product may need transactions, search, event retention, vector retrieval, analytical scans, caches, and object storage before its first major growth curve. Calling all of that a database hides the decisions that determine correctness and cost.

The useful unit is the data product and its access contract. Name the owner, source of truth, write path, read shapes, consistency promise, retention period, recovery objective, and allowed consumers. An engine can then serve that contract without becoming the domain model.

Access patterns should choose the engine

A transactional account ledger needs atomic writes and strong invariants. Product search needs fast retrieval across text and structured filters. Event analytics needs compressed columnar scans over large periods. These workloads can share business nouns while demanding different physical models.

Write down the expected query shape, volume, latency, update pattern, and failure consequence before choosing storage. Prefer one boring authority for each invariant, then build derived indexes and analytical projections from an explicit change stream or scheduled transformation.

Keep authority separate from acceleration

Search indexes, caches, warehouses, and vector stores often accelerate a view of authoritative data. Record that relationship in the architecture. The system needs a way to rebuild each projection, detect drift, and explain freshness to the customer experience that consumes it.

Dual writes without an atomic boundary create ambiguous truth. Use a transactional outbox, durable log, or another explicit handoff when one business change must feed multiple stores. Idempotent consumers and replayable events turn a failed projection into an operational repair instead of a data mystery.

Portability comes from contracts and migration paths

Generic repository abstractions rarely make engines interchangeable. SQL behavior, indexing, consistency, operational tooling, and cost models leak through broad interfaces. A narrow domain repository protects the application because it describes the aggregate operation the product needs.

Real portability comes from export formats, schema ownership, backfills, dual-read validation, and a tested cutover path. Keep engine-specific features when they create material value. Contain them inside the provider that owns the storage decision and preserve a way to move the data safely.

Use fewer authorities and more deliberate projections

Polyglot persistence can become an excuse for infrastructure collecting. Every additional store adds security policy, backup, observability, capacity planning, and incident response. Add an engine when an access pattern has evidence and the current system has reached a named constraint.

Databases remain essential. The dead idea is that one undifferentiated database should define the product architecture. Build around data ownership and customer-facing guarantees, then let storage engines do the specific work they are good at.