Data-intensive applications rarely need one universal database. They need a coherent semantic model and explicit movement among transactional, analytical, search, streaming, object, graph, and vector realizations.
Begin with data obligations
Declare nominal records, invariants, ownership, consistency, transactions, query shapes, change semantics, classification, residency, retention, deletion, throughput, latency, RPO, and RTO. Planning can then compare physical families without changing application meaning.
Do not start by naming an engine and reverse-engineering its current schema into the contract. Provider-specific tuning remains possible through typed configuration attached to the selected realization.
Separate systems of record from derived views
A durable transactional store may feed search indexes, analytical tables, caches, feature vectors, graph projections, and materialized views. Each derived view records:
- its source schema and cursor;
- conversion and loss policy;
- freshness and consistency contract;
- rebuild and backfill path;
- privacy and deletion propagation;
- provider, cost, and observation evidence.
A view can be disposable only when the source and deterministic rebuild path meet its recovery contract.
Plan movement as first-class work
Imports, exports, CDC, replication, rebalancing, compaction, reindexing, backfill, archival, and deletion are typed operations. They carry checkpoints, resource limits, authority, schema mappings, reconciliation, and exact postconditions.
For online changes, use a bounded transition: expand, backfill, validate, switch readers, switch writers, observe convergence, and remove the retired path. Every overlap ends under an explicit condition.
Make global claims local and composable
Strong consistency or total order exists only inside the authority domain that provides it. Cross-region and cross-provider systems identify the scopes in which ordering, atomicity, uniqueness, and freshness hold.
Conflicts use domain-owned resolution or an explicit reject/manual path. A last-writer-wins timestamp is not silently substituted for business meaning.
Prove operations, not labels
A provider that claims durability also proves recovery behavior. A replicated store proves fencing and repair. A multi-tenant store proves isolation and resource fairness. A backup provider proves restore compatibility. A vector or search provider proves the declared quality and freshness bounds.
Planning selects only claims supported by exact, fresh, admitted evidence.
Example
Illustrative planning output explains a rejected data realization:
requirement durability acknowledged
accepted one.data.postgres#Managed@1
rejected one.data.memory#Ephemeral@1: durability unsatisfiedSee data and state and recovery and continuity, then follow the data-backed service recipe or analytical, search, and vector projection recipe.