1. Database writes are tiered - there are three immutable graphs (actually the schema is also a graph but typically will be substituted for the instance graph during updates) and one label
   a. Instance Graph
   b. Repository Graph
   c. Database Graph
   d. Label

These graphs are written to disk with the database graph being absolutely last. The database graph contains reference to the repository graph which in turn knows which branch is associated with the latest update in the instance graph. The label is atomically updated with a revision number only after a successful write of the database graph. This can be either to a label server or to a file depending on the setup.

All of this ensures that all transactions are ACID.

2. This means that:
   a. The data is immediately available if the server which committed the write is the same as the read server. Otherwise, if we are using a different server on the same store it is available after load of the layer from disk.
   b. The ram needed as compares to the transaction depends on what sort of data is being processed, but for JSON documents we generally need around 10x as much ram in a transaction as the total JSON document list size.

Note, since everything is immutable, we can share any number of readers over the same store, and get data distribution using NFS.

3. In terms of Git for Data
   a. The part accessible from RAM is whatever is queried. We keep an LRU of layers and so it depends on which layers are being used. If you are using the complete history all the time and have enough RAM, it might all be in RAM.
   b. History can be hundreds or thousands of commits. Commits on our TerminusCMS server which track new users logins, data products etc. are extremely long.
   c. This depends on optimisations. If you run an optimisation on a commit then you'll end up with a new pseudo-layer which is a bit like a squash called a "delta-rollup" which represents the combined state of the updates. You will retain the historical information but will have an optimised version which is fast to read. Queries will happen against this pseudo-layer unless you ask specific questions about what changed in that commit, or what its parent was.
   d. You can run loads of readers against a given store easily and this will improve performance for queries a lot. For writing we are more bottlenecked and doing parallel writes requires recombinding from seperate transaction domains

   Currently our transaction domains are per data product. We know how to make them per branch but we haven't gotten to it yet unforunately, and it's even possible to get finer grained than that, but pushing further is significantly more complex. We'll try to get to the branch level transaction domain soon.