What delivers better performance: Transaction data "save on write" or "on read"?

Dear Community, i would like to know if i rather should write more often or have more complicated/longer reads on my data source.

Problem setup
I do have a “transaction table”. The table holds a static set (100-10k) rows. The user manipulates the rows via an App. The user sees the last manipulated row for the static set of rows. All manipulations must be saved.

Option on read
The microservice (MS) which is called upon manipulation appends rows. The front end App displays a VDT. The VDT has a “latest logic” to show only the versions of each row which is manipulated lastly. (Here we can leverage an inner join or a window function)

Option on write
The “transaction table” has one more column: “i_am_latest”. The “i_am_latest” column is of boolean type. The MS which is called upon manipulation appends a new row/new rows. However the MS also checks which are the latest manipulations and saves this information in the “i_am_latest” boolean row.
The front end VDT only as a filter to get the latest transaction.

where i_am_latest == 'true'

Use case considerations

  • The VDT is called on several front end elements in different pages.
  • The manipulations are distributed upon only on one or a little amount of users.
  • The user is fully aware of when the manipulation happens.
  • The manipulation screen itself displays the VDT two times. (one graph + one table)
  • More often than not, the user manipulates only one row

A) What happens on “data table save” + “replace” + “force exact match”. Does this trigger a full new dump of the table, or is this a hidden table update? → Is this question relevant for the use case considerations?
B) Can You think of more Considerations? (I will add them to the list)
C) Should i save the “latest information” on read, or on write ?