A financial database role is the kind of answer a store is responsible for returning, such as a committed account balance, a time-specific market observation or a searchable document match. Different roles can use overlapping data without having the same authority or visibility timing.

Committed balances and transaction boundaries

A transactional database can support grouped changes and concurrency controls. The application still defines the financial operation those changes represent. Balanced postings, stable transaction identifiers, currency-aware amounts and reversal relationships belong to the ledger design.

A relational data model does not specify the complete isolation behavior. PostgreSQL supports configurable isolation levels; its documented default is Read Committed. A sequence of statements needs a deliberate transaction boundary if the business result depends on what concurrent operations can change between those statements.

Transactions are also available outside relational engines. MongoDB documents multi-document transactions. The useful comparison is the actual operation and its guarantees, not the assumption that only one database family supports transactions.

Market observations and time-specific queries

A tick store organizes market observations for time-dependent retrieval. The schema needs to distinguish event time, receipt time and correction time. Selecting a designated timestamp makes a particular time axis available to queries; it does not make that axis correct for every financial question.

An as-of join associates a record with an observation at or before a selected timestamp. Joining a trade to the latest preceding quote answers a temporal question only if the timestamp and identifier relationship match the intended analysis.

Search visibility and ledger authority

A search index supports retrieval over an indexed representation. Its visibility boundary can differ from the commit boundary of the source record. Elasticsearch, for example, documents a refresh boundary for search visibility.

Take a ledger posting committed at 10:00:00 and indexed at 10:00:02. During those two seconds, the authoritative balance includes the posting while search returns the earlier projection. A search miss during that interval does not establish that the posting failed. Retrying the financial instruction on that basis risks confusing delayed visibility with missing execution.

A controlled projection retains the source identifier, source version and processing position needed to compare it with authoritative state. Search freshness and ledger correctness are then separately observable properties.

Assigning authority to database roles

One engine can serve several roles, and one financial application can use several engines. What must remain explicit is the output contract: which record is authoritative, what time the answer describes, how corrections propagate and how recovery reestablishes consistency. Duplicated data is interpretable when those contracts and reconciliations are defined.

Questions about transaction isolation

Does a successful database transaction prove the balance is correct?

No. Atomic execution does not establish correct posting rules.

Can one database support more than one role?

Yes. The roles describe required behavior, not a mandatory number of products.