Most relational databases offer serializable isolation as their strongest consistency guarantee. Strict serializability is stronger, and the difference is not academic. For a financial settlement ledger, the gap between the two can be the difference between a system that requires a reconciliation job and one that does not.
What Serializable Isolation Actually Guarantees ¶
A serializable database guarantees that the result of executing a set of concurrent transactions is equivalent to some serial execution of those transactions. It does not guarantee which serial order. It does not guarantee that the order is consistent with real time. Two transactions that a human observer would say happened in a clear sequence may be ordered differently in the database's internal history, as long as the result is consistent with some valid serial execution.
The Additional Guarantee That Strict Serializability Adds ¶
Strict serializability adds linearizability to serializability. The serial order the database chooses must be consistent with real time: if transaction A commits before transaction B starts, then A must appear before B in the serial order. This rules out a class of anomalies where a transaction reads a state that is internally consistent but does not reflect the real-time order of events. For a settlement system, this means a trade confirmation cannot be processed before the trade that generated it, even under high concurrency.
Why Weaker Isolation Levels Require Application-Level Workarounds ¶
Systems running at read committed or repeatable read isolation frequently add application-level locking, retry logic, and reconciliation jobs to compensate for the anomalies those levels permit. Each workaround is a maintenance burden and a potential source of new bugs. The reconciliation job that runs every four hours is not a feature; it is evidence that the database's consistency guarantees are insufficient for the workload.
How Grit Core Lab Enforces Strict Serializability ¶
Grit Core Lab uses multi-version concurrency control with a strict timestamp ordering at the storage layer. The timestamp is assigned by the leader at the start of each transaction and is monotonically increasing. Conflicts are detected before commit, not after. There is no configuration option that weakens this to a lower isolation level. The guarantee is structural, not advisory.
For teams evaluating database options for FSA-regulated workloads in Japan, the consistency model is worth examining carefully before the migration decision is made. The technical questions section on this site covers the specifics of Grit Core Lab's implementation.