Summary
One Postgres database currently holds several different kinds of truth. That is an economical deployment choice, not permission to treat every table as one shared model. Analytical history, interactive workflow state, and execution records answer different questions and change under different rules.
Problem
A shared database makes the shortest path dangerously convincing. A route can join a current review case to a raw analytical table. A pipeline can update an operator queue as a side effect. A job can keep its business state beside its run log. The query works, the screen loads, and the architectural debt remains invisible.
But what happens when an analytical rebuild changes history while a person is making a decision? Which record is authoritative when a retry overlaps a manual repair? And can we later move the analytical workload without rewriting every surface that learned the physical schema?
Those are ownership questions. Colocation does not answer them.
Principle
We treat physical colocation and conceptual ownership as separate decisions. The platform can use one database now while preserving contracts that make OLTP state, lakehouse truth, and execution support independently understandable and, eventually, independently deployable.
Platform Shape
The lakehouse schemas—bronze, silver, and gold—own ingestion, normalization, history, and analytical publication. They are designed to be rebuilt and to explain how a fact was derived.
Domain OLTP schemas own the state people act on: cases, issues, approvals, queues, locks, and UI-serving records. That state is transactional, tenant-scoped, and tied to an actor or workflow decision. The ops schema owns execution and support state such as job and DAG runs, schedules, synchronization audit, and messaging support. A run record can explain how work executed; it does not become the business case the work was trying to advance.
The boundaries show up in the code path. A UI reads operational state through an authenticated capability or an explicit serving snapshot, not by composing raw lakehouse joins. A pipeline publishes facts or signals; it does not quietly decide a human review. A job records its attempt through the execution platform rather than keeping the only evidence in process memory.
Sometimes this costs an extra publish step. That step is useful friction. It names the grain, freshness, lineage, and ownership of the data crossing from an analytical context into an operational one. The shortcut would save a small amount of code by leaving the next maintainer to infer all four.
Tradeoffs
One database is simpler to operate today. Conceptual separation inside it is harder to see than separate network boundaries, so discipline has to come from service interfaces, session ownership, tests, and repository rules.
We do write more explicit publication and adaptation code than a direct query would require. That does not prove a physical split will happen, or that it would be beneficial now. It preserves the option while making today's system safer: the person repairing operational state does not have to reason about a rebuildable analytics pipeline at the same time.