Skip to main content
Gateway depends on storage not just to remember events afterward, but to control which effects may happen next. That makes transaction ownership, current permissions and recoverable history part of the execution design. Two distinctions help explain the database model: who owns a fact and where that fact is physically stored.

​
One database can contain several owners

The company core direction describes PostgreSQL 17 with per-engine schema, owner and runtime boundaries. That permits shared physical infrastructure without giving every engine authority over every table. Gateway owns its execution records. Native capacity, application content and financial records retain their own defined responsibilities. A shared connection pool or schema name is not a permission grant. The isolated Gateway experiments used their own role arrangements. In particular, a non-login object owner in an O1 fixture is not evidence of a universal company rule; the reviewed core owner roles had a different login profile.

​
Required effects must share one transaction

Where the selected Gateway profile requires coupling, an attempt registration and its native-capacity reservation use the same actual database backend, connection and transaction. If the transaction rolls back, neither half should remain as a misleading partial success. The same principle applies to terminal, successor and final boundaries under their accepted grouping. Two helpers that independently commit are not equivalent, even if each operation is individually idempotent. A crash between those commits can separate capacity from the execution record it was meant to support. Provider network work happens only after the relevant registration is confirmed, outside the database transaction.

​
Serving, recovery and confirmation are different permissions

The design separates normal execution writes, recovery, correction, settlement acknowledgement and protected readback. A process allowed to serve a call does not automatically have permission to inspect private native witnesses or acknowledge money results. Installed database functions and effective grants must enforce the intended boundaries. A role diagram in a document cannot prove those grants are actually in place.

​
Restored history must still be authoritative

A database restored from an older backup may lack a record that previously committed. Treating that absence as proof of nonexecution could cause old work to look new. Recovery therefore needs the correct current generation, acknowledged history and fencing of stale writers. Confirmation must establish the whole applicable execution and native graph, not just find one row with the right identifier. The stricter native-history profile retains its selected three-PostgreSQL-instance and required durable-flush constraints. A simpler “two copies are enough” explanation must not silently replace that requirement. Physical deployment and failure-domain qualification need their own evidence. Read When a confirmation is lost for the request-level consequence, and Recovery after a storage failure for the operational one.