Summary
One Postgres database can make several kinds of truth look interchangeable. They are not.
Analytical data answers what was ingested, normalized, enriched, and published at a particular grain and vintage. Operational data answers what a tenant can see, review, decide, and repair now. Execution state answers what ran, what attempt failed, and what can resume. All three live in the same physical database today, but each carries different promises about time, ownership, and recovery.
The convenient query is therefore not always the cheap query. A direct join can save an interface this afternoon while quietly binding a screen to analytical freshness, a pipeline to human workflow state, or a retry to process memory. We separate responsibility before infrastructure because those hidden bindings, not the number of database instances, determine how hard the system is to change.
Operational Tension
The needs pull in different directions. Analytics must be rebuildable and historically intelligible. Operational workflows need current, tenant-scoped, auditable decisions. Execution needs durable attempts and recovery context.
When a UI assembles business state from raw analytical joins, it inherits the lakehouse's grain, freshness, and rebuild behavior without naming any of them. When a pipeline writes review state directly, it assumes ownership of a human workflow it cannot present or repair. When a job remembers its run only in a process, an interrupted worker takes the recovery evidence with it.
None of these failures begins dramatically. They begin as local convenience, then cross a handoff, and finally surface as stale state, missing accountability, or a recovery path that depends on someone remembering how the code worked.
Decision: Separate Ownership Before Infrastructure
The architecture gives each responsibility an owner even while storage is shared. bronze, silver, and gold own ingestion, canonicalization, enrichment, historical fact, and analytical publication. OLTP and domain schemas own interactive workflow state. The ops area owns execution and support state. Names may evolve. The durable rule is that ownership, not table proximity, determines how a consumer reaches the data.
The bridges are explicit. Analytics reaches an operational surface through a publish step, serving snapshot, or authenticated OLTP-facing service or repository. UI code does not manufacture business state from raw analytical joins. Cross-boundary foreign keys, shared persistence models, and transactions do not silently turn analytical and operational state into one unit of change. Temporary coupling sits behind an interface and is documented as a migration seam.
This lets us use the database we have without pretending it is the final topology. Separate OLTP and analytics connections remain a real future option because current code is not allowed to erase the boundary for convenience.
Failure And Repair Posture
A failed boundary should expose its owner, not invite a shortcut. If an analytical projection is stale or fails a quality check, the repair belongs in the pipeline or publication path with freshness and lineage evidence. The UI does not make the symptom disappear by reading a raw table. If review state is missing or inconsistent, the domain workflow and its audit trail own the repair; a backfill should not invent user-facing state without context.
Execution follows the same discipline. Durable run and attempt records make stale leases and recoverable failures inspectable. A rerun can be bounded and explained rather than inferred from a vanished process. The kinds of truth have different failure semantics, but each leaves enough evidence for the right owner to act.
Tradeoff
Explicit publication and service boundaries add steps. They may duplicate selected data, require freshness contracts, and reject a tempting cross-schema join. The cost is especially visible while every table is physically close.
What we buy is controlled change. Analytical rebuilds can evolve without silently rewriting an operator's experience. A review workflow keeps its audit contract instead of becoming a transformation side effect. Execution recovery can change without absorbing domain policy. If storage eventually separates, fewer accidental contracts need to be excavated first.
Limits
This proves that ownership can be separated before databases are. It does not isolate runtime load, access control, or failure domains while storage remains shared, and it does not justify a service boundary no workflow needs. The rule must be carried through repositories, APIs, cache keys, object paths, and task payloads—not merely drawn in a diagram. No physical split is claimed to be planned or imminent.
Transferable Lesson
A shared database is an implementation choice. Ownership is an architectural choice. Name the promises each kind of state makes, define the bridges between them, and preserve a repair path at every boundary. A future split can then be an evolution of interfaces instead of a search for assumptions hidden in every screen and job.