One separates what data means, how it is represented, where it is stored, and how it moves. Those are related decisions, but they do not have the same owner or the same lifecycle.
Semantic schemas are not storage schemas
A contract owns nominal values, constraints, compatibility, faults, and mappings. Data owns physical layouts, transactions, indexes, queries, durability, replication, backup, retention, and deletion. An application can therefore require serializable order updates without turning PostgreSQL—or any other engine—into part of the order contract.
Planning selects a physical representation only after validating every conversion edge. Each edge records what it preserves, copies, borrows, reorders, defaults, narrows, widens, or loses, together with its cost, allocation, trust boundary, hardware requirement, and evidence.
Loss is never inferred from a successful decode. If no acceptable path exists, the plan is unsatisfied.
One data model, many physical families
A root can compose relational, key-value, document, graph, time-series, vector, object, full-text, cache, log, queue, and stream capabilities. These families share the small contracts that genuinely overlap—identity, buffers, transactions, cursors, change, retention, and evidence—without being flattened into one lowest-common-denominator database.
Queries retain their semantic result and consistency requirements while the selected provider owns physical optimization. Statistics and cost evidence inform planning; provider-specific plans remain inspectable and replaceable.
Transactions and effects stay distinct
A transaction can make a bounded state transition atomic within its authority domain. It does not make an external API call, message delivery, payment, or email part of that atomic domain.
Cross-boundary work uses explicit patterns such as an outbox, inbox, idempotency key, effect journal, compensation, or observation query. The system records exactly which guarantee applies. “Exactly once” is never claimed across a boundary whose protocol cannot prove it.
Continuity is a contract
Durability, availability, replication, partition tolerance, RPO, RTO, residency, retention, and recoverability are independent dimensions. A plan must bind each requested claim to executable provider evidence and an operational path.
Stateful failover includes fencing, replication position, compatibility, promotion, routing, repair, and split-brain prevention. Backup includes retained source ranges, encryption, integrity, restore compatibility, and a tested restore path. A snapshot without lineage is data, not recovery authority.
Evolution keeps three revisions distinct
Semantic schema revision, the schema and codec under which a value was accepted, and physical layout revision are separate coordinates. A compatible change does not by itself authorize rewriting bytes. One Database reads an optional addition, defined default, admitted widening, or other total Contracts-owned conversion at the requested revision without blocking DDL, physical rewrite, a migration script, or hidden request-time mutation. Another provider must expose its exact conversion and any physical work rather than presenting storage compatibility as semantic compatibility.
A breaking change is planned data movement. One models its exact source snapshot, typed transformation, target materialization, change catch-up, validation, old-writer fence, cutover, rollback window, and cleanup as explicit actions with bounded coexistence.
Every movement declares source and destination schemas, conversion profile, loss policy, throughput, checkpointing, reconciliation, privacy, residency, and deletion obligations. A migration is complete only when its semantic postconditions are observed—not when a tool exits zero.
Tenancy and privacy are structural
Tenant identity, subject scope, classification, encryption, access paths, retention, erasure, residency, and audit obligations enter the data closure. The selected realization must show how it isolates data and how that isolation is enforced.
Immutable causal headers can coexist with erasure by separating protected payloads and subject mappings from retained fact identity. Erasure is an authorized event with a visible tombstone, not silent history rewriting.
Example
Illustrative end-product syntax states obligations without choosing storage:
state Orders@1
key (CustomerId, OrderId)
value Order
consistency read_your_writes
retention 7y
erasure by_customer
Follow Build a data-backed service.
Canonical owners: Contracts and Data.
Next: resources and lifecycle.